Comment by omoikane
3 days ago
> I think this page describes "what" but not "why" of Carbon.
Maybe the page was updated recently, but there is a "why" link near the top:
https://docs.carbon-lang.dev/#why-build-carbon
What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any reference to it.
The reason the Safe C++ proposal wasn't mentioned is that it came years later. =] I'll see if it makes sense for us to update that section a bit, this probably isn't the only thing that we should refresh a bit to reflect the last few years of developments.
FWIW, the biggest challenge with Safe C++ is that WG21 rejected[1] that direction. And it was developed without building a governance model or way to evolve outside of WG21, and so doesn't seem to have a credible path forward.
[1]: FWIW, some members of WG21 don't agree with this characterizationp, but both the author's impression and the practical effect was to reject the direction.
To your footnote, this has been a constant refrain from WG21. One of the biggest achievements from yourself and many others was getting WG21 to explicitly reject P2137 the "Goals and priorities" paper rather than dithering and refusing to commit as happened for "Safe C++" and for the ABI paper.
I believe that getting WG21 to actually say "No" was very useful to have non-technical leadership people understand that C++ can't be the solution they need.
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.
> 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?"
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.
3 replies →
Most languages including C and C++, had leading closed source implementations, that is why being standardised by ISO mattered.
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.