You are saying "yes" to a comment explaining why the Google AI response cannot possibly be correct, so what do you mean "and [it's] correct"?
BatmanAoD
joined 1 year ago
This article somehow links to both the Reference and the Ferrocene spec, but still concludes that an official non-Ferrocene spec is necessary.
Why doesn't the Ferrocene spec accomplish what the author wants? He states:
In other words, without a clear and authoritative specification, Rust cannot be used to achieve EAL5.
What? Why can't the Ferrocene spec (and compiler) be used? Do Ferrocene and TÜV SÜD not count as "some group of experts"?
(Regarding the author's opening paragraphs, the Reference does make the same distinction about drop scopes for variables versus temporaries, though I can see why he finds the Ferrocene spec clearer. But that doesn't demonstrate that the Reference is useless as a stand-in for a specification.)
That's actually not how any language has ever been written, though it's easy to get that impression from how much the C and C++ communities emphasize their formal specifications.
But in fact, both languages were in production use for over a decade before they had a formal spec. And languages with formal specifications are actually a tiny minority of programming languages.
There is indeed a caveat in the introduction to the Reference that there may be statements in it that are specific to rustc. However, the authors strive to keep statements about the implementation separate from statements about the language.
The main reason there's not yet an "official" spec is that creating one takes enormous time and money, which are always limited resources. (Note that both C and C++ had no formal standard for over a decade after their initial release.) The Reference is "good enough" to make a formal spec not strictly necessary, and the existence of Ferrocene makes it even less necessary, since anyone who absolutely needs a spec can use Ferrocene.
You can say the Rust implementation is wrong if it doesn't conform to the Reference. That is not the same as "you personally disagree with the behavior."
Rust's guarantees about the behavior of safe code are far stronger than anything C or C++ provides, with or without a formal spec.
Creation is easy, assuming the many-worlds interpretation of quantum mechanics!
Delete prior iterations of the loop in the same timeline? I'm not sure there's anything in quantum mechanics to permit that...
In the universe where the list is sorted, it doesn't actually matter how long the destruction takes!
Reminds me of quantum-bogosort: randomize the list; check if it is sorted. If it is, you're done; otherwise, destroy this universe.
Or Stockholm Syndrome
You're not wrong, but not everything needs to scale to 200+ servers (...arguably almost nothing does), and I've actually seen middle managers assume that a product needs that kind of scale when in fact the product was fundamentally not targeting a large enough market for that.
Similarly, not everything needs certifications, but of course if you do need them there's absolutely no getting around it.
I care about types not just because I like having stronger confidence in my own software, but because, as a user, bugs are really annoying, and yes, I'm confident that stronger type systems could have caught bugs I've seen in the wild as a user.