That sounds like the hallmark of a defective language to me.
* Rust
* Python
* Ruby
* PHP
* TypeScript
Last updated Jan 2016.
[1] https://javascript.xgqfrms.xyz/pdfs/TypeScript%20Language%20...
Here's my line in the sand: After the Mother of All Demos, if you're trying to agree things internationally and you are physically moving people to a location to do that you're doing it wrong, but maybe you don't know that yet. After JIPS ceases to be a pilot project, not knowing you're doing it wrong means you're grossly incompetent.
Those two dates are somewhat arbitrary, I picked them deliberately but I can entertain other nearby events for the same purpose. In particular if you're in Asia or Africa the JIPS date seems very arbitrary, I pick it because in my opinion this outcome (The United Kingdom's tertiary education will use IP not X.series standards) firmly means the Third Network will be the Internet not the X.25 standard. X.25 can win if only the Americans do IP, but it can't once IP spreads and that's what JIPS is.
I'm far from convinced Rust should have standardization via some SDO, but if it did need that then I'm sure ISO is the last place to go. ETSI isn't great, but it's already better than JTC1. If some corporates insist on an ISO document, mint the document somewhere else and just get ISO to put their stamp on it, have the corp. pay for that - but tell anybody who cares to ignore the stupid ISO document.
You (Steve) undoubtedly know that C++ 23 is a thing, they signed off on it mostly in 2022 and a little bit of 2023, but because ISO is awful actually ISO/IEC 14882:2023 doesn't exist, they are still working through the tedious process of agreeing to publish a document everybody settled on twelve months or more ago.
This process was fine for, I dunno, standardising how the plastic joints fit together on a water pipeline. Maybe it takes a few years to nail down exactly the text, you standardise it, nobody needs to revisit for decades at least. It's stupid for a programming language.
Usually, it’s just some core calculus of the language that is rigorously specified and the rest is hand waving.
There are some exceptions like JS.
But even Java has the problem that if you just implement what’s in the spec, you won’t be able to run anything meaningful unless you also do things exactly how the JDK would. You can find out what the JDK does by reading its code and writing test cases and I think that’s what folks do, if they want to be compatible.
UB and memory safety are orthogonal. If we specified formally and super rigorously that a pointer is an integer and that memory is an array of bytes, we could have a UB-free language but memory safety would still be on fire.
That's PVI (Provenance Via Integers) and it's a performance disaster. If anything in memory might be pointed to, almost all the nice modern optimisations aren't correct. It is really popular with a certain kind of "Portable assembler" programmer, who typically has no idea how the machine actually works, nor how their language is defined but is very confident the nonsense they're writing ought to do what they wanted it to do.
So, the "bad" news is that you can't have this, your compiler vendor won't make it, and the "good" news is that you'd have hated it anyway which is why they won't make it.
JS is maybe closer on this front but it's also quite old & JS is also a mess & a lot of development has shifted to TS as the language for those reasons & TS only has 1 frontend & no formal spec.
Still, if memory serves there have been a handful of cases where egc's implementation of the spec differed from javac's with resulting fixes in javac itself (though I don't have sources at hand, so perhaps I misremember).