[steveklabnik]

> C is a language that's basically built on memory aliasing

Additionally, C does actually have aliasing rules, but many projects, including the kernel, turn them off. Linus in particular does not think they're worthwhile.

These rules are different than Rust's, Rust also rejected these particular rules.

> To take a quote from the D manual [0], to guarantee memory safety you need to disallow

Just to be clear, this is the list for D, not in general. Rust is fine with you taking the address of a local variable or function parameter.

[tremon]

> C does actually have aliasing rules

If you're referring to e.g. gcc's -f[no-]strict-aliasing option, then that's more about type compatibility than about limiting the scope of memory aliasing in general. If you mean something else, I'm interested to hear more.

> this is the list for D, not in general

Yes, I know. But it's the first authoritative source I could think of on memory safety in C-like languages. I don't think the list is wrong for C proper, just probably not exhaustive.

> Rust is fine with you taking the address of a local variable

Yes! But circling back to the earlier point: in Rust you can do this specifically because the language has well-defined lifetime semantics on variables and ownership. And as such, Rust can guarantee that a) a pointer to a memory location does not outlive the scope of the memory allocation itself, and b) when two variables/pointers refer to the same memory location, there is a compiler-enforced protocol for accessing and mutating that memory.

[steveklabnik]

> then that's more about type compatilibity than about limiting the scope of memory aliasing in general.

It's about limiting the ability of pointers to alias. The C standard even has this parenthetical:

> The intent of this list is to specify those circumstances in which an object can or cannot be aliased.

You are correct that it's a pretty narrow set of rules. There are only six items on that list. But it's still an aliasing rule.