undefined

points

[-]

I believe these two statements should show the fundamental difference:

- If a safe Rust program exhibits a memory safety problem, it is a bug in the Rust compiler that is to be fixed - If a Zig program exhibits a memory safety problem, it is a bug in the Zig program that needs to be fixed, not in the compiler

Wouldn't you agree?

> Ferrocene is intended to document the behavior of the current version of the rustc compiler, so it's just an effort to formalize "the compiler is the language".

I must admit I haven't read the specification, but I doubt they attempt to be "bug for bug" compatible in the sense that the spec enumerates memory safety bugs present in the Rust compiler. But am I then mistaken?

by ummonk2 hours ago|

parent|

[-]

No, I don't agree. A compiler bug is something that gets fixed in a patch release after it's reported, or perhaps some platform-specific regression that gets fixed in the next release after it's reported. What we're discussing by contrast is a soundness hole in the language itself - one which will most likely require breaking changes to the language to close (i.e. some older programs that were perfectly safe will fail to compile as a side effect of tightening up the Rust language to prevent this soundness hole).

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."

Proposals to fix the soundness hole in Rust either change the variance rules themselves, or require where clauses in certain places. Either of these changes would require corresponding changes to chapter 4 of the Ferrocene specification.

by steveklabnik1 hours ago|

parent|

[-]

> 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 ummonk27 minutes 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-Curunir2 hours ago|

parent|

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 vlovich1232 hours ago|

parent|

prev|

[-]

> If a safe Rust program exhibits a memory safety problem, it is a bug in the Rust compiler that is to be fixed - If a Zig program exhibits a memory safety problem, it is a bug in the Zig program that needs to be fixed, not in the compiler

That is the absolute best description of memory safety I’ve heard expressed.