Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

▲

aw1621107 5 days ago | parent | next [-]

> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation?

Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation!

Well, unless the implication that Circle isn't "full, correct, [and] fully compliant", in which case I feel I should ask "with respect to what?" and "why do you need those requirements?"

▲

justcuriousab 5 days ago | parent [-]

But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

▲

aw1621107 5 days ago | parent [-]

> But Safe C++ and Circle are different languages, right?

Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe Safe C++ as a subset of the Circle extensions. I wouldn't exactly describe the lines as well-defined, for what it's worth.

> There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere.

They're sort of documented indirectly, as far as I can tell. Compare the features in the Safe C++ proposal and the features described in the Circle readme [0]. That'll get you an approximation at least, albeit somewhat shaded by the old docs (understandable given the one-man show).

> I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

The exact words "reference implementation" may not show up, but I think this bit qualifies (emphasis added):

> Everything in this proposal took about 18 months to design and implement in Circle.

[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...

▲

saghm 4 days ago | parent [-]

If they're the same language, then I think it's a fair objection that it's closed-source, as some people might find using a closed-source compiler to be unsuitable as a replacement for the existing open source C++ ones. If it's not the same language, then it's not clear that Safe C++ actually exists today, so it also seems fair that people might be interested in alternatives that they expect might be available sooner.

▲

aw1621107 4 days ago | parent [-]

I don't think the objection in the first sentence makes sense because I don't think replacing the existing C++ compilers was ever in the cards. If anything, the fact that the Safe C++ proposal has a section titled "Implementation Guidance" seems to point to precisely the opposite - that the intent was for existing C++ compilers to be updated to add the new features, not that Circle was to replace them.

I'm not sure about the second sentence either? Circle (supposedly?) implements everything in the Safe C++ proposal, so in that respect Safe C++ exists. Alternatively, you can say Safe C++ doesn't exist because major compilers don't implement it, but that's kind of the point of the Safe C++ proposal (and many (most?) other C++ language proposals, for that matter) - it's describing new features that don't currently exist but might be worth adding to the standard.

> people might be interested in alternatives that they expect might be available sooner.

This is also a bit funny because this was one of the more contentious points of debate in the Safe C++ vs. profiles discussion, and the impression I got is that between the two Safe C++ was generally considered to be closer to "might be available sooner" than profiles.

▲

saghm a day ago | parent [-]

It sounds like the difference of opinion here is around how soon we expect that the major compilers will actually implement the safe features. I tend not to be optimistic that these sorts of changes will be available anytime soon, and I think it would be fair to consider alternatives at this point, but that's obviously a judgment call and not everyone will agree on that.

	▲	aw1621107 a day ago \| parent [-]
		As far as Safe C++ vs. profiles specifically, I don't think the conversation really ever got to the point of serious discussions of how soon the features could be implemented. My understanding is that there were bigger hangups about what direction to go in the first place as well as what "profiles" even meant. > and I think it would be fair to consider alternatives at this point I would assume those who could consider alternatives already have, and that those (still) interested in safe(r) C++ do so because the alternatives are insufficient for one reason or another.

▲

pjmlp 5 days ago | parent | prev [-]

Most languages including C and C++, had leading closed source implementations, that is why being standardised by ISO mattered.

	▲	justcuriousab 5 days ago \| parent [-]
		But standardization also matters for avoiding vendor lock-in, right? Like, Python and Javascript both have many "implementations", and those are some of the most popular languages. Python does not have an ISO specification. But Javascript does have an Ecma standard, ECMAScript. Rust is getting another implementation in the form of gccrs. And there is work on a specification for Rust https://rustfoundation.org/media/ferrous-systems-donates-fer... . Arguably not a standard, but still helpful.