AFAIK there isn't a language spec. Rustc is the language for now.
replyBut bugfixes are also allowed. So the fair conclusion is that the implementation is broken, but the language is not - because it's possible to fix, and it's possible for all known soundness issues (including the cve-rs one). For this one specifically, I've heard people are already working on a fix.
reply[flagged]
replyMy understanding is that it is work in progress, via Ferrocene.
replyFerrocene is not a separate implementation of the compiler. It's the same Rustc, just a few versions behind and with a bunch of regulatory approvals attached. There is ongoing work on fixing all the unsoundnesses, happening as part of the main compiler development: https://goals.rust-lang.org/2026/roadmap-project-zero.html
replyFerrocene has his same flaw
replyIf that's the case then I was wrong.
replyWhich clause of the language specification is being violated?
replyLifetimes can be effectively erased via covariant assignment.
It's in the title.
Even a beginner could understand these assignments are not in spec?
Are you just being contrary to be contrary?
replyIf that's the definition you're using, then C is also a safe programming language. In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.
reply> In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.
replyThe difference is that the C spec intentionally frees the compiler from upholding those invariants. In this case the Rust compiler is failing to catch something it is required to catch.
A more accurate analogy would be a C compiler incorrectly failing to reject an assignment through a pointer to const without a cast. The spec requires that such a thing be rejected, so it's a compiler bug.
So point to the spec
replyhttps://public-docs.ferrocene.dev/main/specification/types-a...
replySpecifically the `q.0 = Some(&l);` violating 4.15.2:40 ("An assignment expression requires that the type of its value operand is a subtype of the type of its assignee operand.")
That's a pretty basic property of any language. Why does the rust compiler fail to enforce it in this case?
reply> Why does the rust compiler fail to enforce it in this case?
replyA bug. The one linked, that we're all talking about.
Feel free to share a link to any software that has zero bugs.
this is probably a great opportunity for rust to get one, if they want to be taken seriously
replyI totally understand that people have favourite languages and that rust, like any language and any ecosystem around that language, has idiosyncrasies that are not for everyone, but how would one ever come to the genuine conclusion that rust is not being taken seriously? By whom?
reply