[wahern]

I know Rust doesn't do "strict aliasing", literally speaking. But that's partly because Rust's borrowing rules change the framing of the term strict aliasing as used in C, etc. It's similar for terms like "undefined behavior", where there's sometimes a certain amount of pedanticism from Rust developers that merely serves to deflect the point of contention.

Is this wrong? https://doc.rust-lang.org/nomicon/aliasing.html Specifically

> In the previous example, we used the fact that &mut u32 can't be aliased to prove that writes to output can't possibly affect input. This lets us cache *input in a register, eliminating a read.

[steveklabnik]

Yes, it is a completely different set of rules. Strict aliasing is also referred to as type based aliasing analysis. Rust has categorically rejected this form of analysis, the aliasing rules are very different. It has nothing to do with types.

[steveklabnik]

Oh, and "undefined behavior" has effectively the same definition in Rust and in C and C++. There's wording differences:

C/C++: behavior for which this document imposes no requirements

Rust: is not bound by any specification

But that's just a wording difference, not a semantic difference.

There are some instances where Rust and C/C++ use similar words to mean different things, but that's also changed over time. For example, Rust used to use rvalue and lvalue, but has moved to

"place expression", defined as "lvalue" in C and "glvalue" in C++

"value expression", defined as "rvalue" in C and "prvalue" in C++

The only reason to not use the C++ terms here is that these are the only two value categories in Rust, and it's unlikely to need all of the other three that C++ has.

You're not wrong that there's stuff called the same but has different meanings, for example, "reference," but what can you do.