> I suspect that if Rust continues forward with this approach it will basically end up as the code where someone goes to read the actual semantics to determine what the C code should do.

That will also put it on the unfortunate position of being the place that breaks every time somebody adds a bug to the C code.

Anyway, given the cultures involved, it's probably inevitable.

▲

mustache_kimono 9 hours ago | parent [-]

> That will also put it on the unfortunate position of being the place that breaks every time somebody adds a bug to the C code.

Can someone explain charitably what the poster is getting at? To me, the above makes zero sense. If the Rust code is what is implemented correctly, and has the well-defined semantics, then, when the C code breaks, it's obviously the C code's problem?

▲

Sharlin 7 hours ago | parent [-]

I think a charitable interpretation is that given that the Rust code will be less forgiving, it will "break" C code and patterns that "used to work", albeit with latent UB or other nonobvious correctness issues. Now, obviously this is ultimately a good thing, and no developer worth their salt would seriously argue that latent bugs should stay latent, but as we've already seen, people have egos and aren't always exceedingly rational.

	▲	marcosdumay 3 hours ago \| parent [-]
		Well, thanks. It's not exactly that the Rust implementation will be less forgiving. But developers will have a clear picture of the operations semantics, while C developers will have a harder time understanding the operations, and consequently avoid them.