undefined

points

[-]

> As to the Ferrocene specification, it explicitly states "Any difference between the FLS and the behavior of the Rust compiler is considered an error on our part and the FLS will be updated accordingly."

Right, this is from before it's adopted as the actual spec, because it was from outside the project, and so could not be.

Also, these goalposts are moving: it was "Rust doesn't have a spec" and now it's "I don't like the spec."

Fixing this soundness hole does not require a breaking change to the language. It is an implementation bug, not a problem with the language as specified. But even if it were, Rust's policies around soundness do allow for this, and the project has done it in the past.

by ummonk4 hours ago|

parent|

[-]

The goalposts haven't moved. The goalposts were always "the current compiler is the language".

If there is a proposed fix to the soundness hole that wouldn't reject some existing sound Rust code, please link to it; none of the proposed fixes I've seen do so. And yes, Rust's policies do allow for breaking changes in pursuit of soundness - likely some day many years from now safe Rust will indeed be sound and guaranteed to be memory safe.

by Ar-Curunir6 hours ago|

prev|

[-]

And Rust has and will make those breaking changes, while Zig will likely not. In fact there are documented and blessed ways to break memory safety in Zig, and no one is calling them soundness bugs!

I really don’t see how you can claim with a straight face that the two approaches are the same.

by ummonk3 hours ago|

parent|

[-]

"In fact there are documented and blessed ways to break memory safety in Zig" - just as there are in Rust... even the Rust standard library makes liberal use of them (thereby making any program which invokes those parts of the standard library transitively unsafe by definition).

Look, I'm not saying the Zig and Rust approaches are the same. I explicitly stated that Rust is more memory safe than Zig (which is in turn more memory safe than C/C++).

This is because Rust has clearly delineated a "safe" subset of Rust which you have to explicitly opt out of that is mostly sound (and has a goal of eventually being entirely sound), has a culture of encouraging the use of the safe subset, and has taken a good approach to the interfacing of safe and unsafe code (i.e. if unsafe code is properly written and satisfies the exposed contract - despite the compiler being unable to verify this - then safe code can safely be linked with it).

All of this results in extremely low risk of memory corruption for Rust programs in practice (far lower than any other commonly used non-GC language with the sole exception of SPARK).

What you can't do though is reject the notion of memory safety being a sliding scale and draw a binary distinction between languages that are 100% perfectly memory safe and languages that are memory unsafe. Well you can, but Rust will fall on the side of memory unsafe for many years to come. Java (ignoring vendor-specific extensions) falls on the safe side though - the language semantics as specified are sound and it doesn't even have an unsafe subset.