> What does that even mean in the absence of a formal standard and competing compiler implementations?
It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says).
They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.)
> Powerful features allow for powerful takes on crappiness.
I don't know what this means.
> Unless you want Rust to stay a teaching language forever
A lot of companies big and small are using Rust in production so this is not a compelling premise.
"Undefined behavior" in a C++ context is a legalese feature of the ISO standard. The standard defines, very precisely, the behavior of a compliant C++ compiler. In places where behavior cannot be specified (for logical or practical reasons), the behavior is marked as "undefined".
In absence of a standard effectively every language construct is 'undefined behavior'.
I have zero reason to believe that Rust won't meet Python's fate.
The Rust people don't have a standard and don't understand why they need one; in fact, their lack of standards is somehow touted as a benefit. Apparently, people think that if there is no standard for "defined" and "undefined" behavior that everything is "defined" by default.
(They're absolutely wrong, of course; it's actually the opposite.)
What you seem to be describing is "unspecified behaviour" or "implementation defined behaviour". If your program contains undefined behaviour the compiler makes no guarantees about how your program will behave.
No. If we accept your argument then this would be correct:
> In absence of a standard effectively every language construct is 'implementation defined behaviour'.
But the parent said:
> In absence of a standard effectively every language construct is 'undefined behavior'.
Undefined behaviour != implementation defined behaviour. Both of these things exist in C and are separate. You can rely on implementation defined behaviour giving some consistent result on a given, compiler and hardware. You cannot rely on the behaviour of your program if you hit undefined behaviour.
I didn't state 'implementation defined behavior' which encompasses more than the Rust implementation. The Rust implementation defines the behavior, for example signed int overflow.
That's clear enough for programmers to rely on. It is nonsense to argue that this is equivalent to C's "the compiler may do anything it wants" just because the "Rust Book" is not called the "Rust Standard" or not "formal" enough.
It means that when the language designers are asked "what is the behavior of this code (that compiles and doesn't use 'unsafe')?" they never throw up their hands and say "it's undefined behaviour, you must not write that code" (as the C++ definition often says).
They may say "oops, we're not sure what it should do, we need to clarify the language definition and write some tests to ensure the compiler does that". (This happens in C++ too.)
> Powerful features allow for powerful takes on crappiness.
I don't know what this means.
> Unless you want Rust to stay a teaching language forever
A lot of companies big and small are using Rust in production so this is not a compelling premise.