[CheezeIt]

There could be some loophole. If the program globally never makes a reference to a field, must it be aligned? If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

[Ericson2314]

> If the program globally never makes a reference to a field, must it be aligned?

That would be whole-progam analysis which isn't done.

> If the field is referenced, could it be that when making a reference, the field gets copied or moved out and a reference is implemented as a pointer to that copy?

This breaks down with mutation, especially atomics, which are allowed as struct fields.

[CheezeIt]

> That would be whole-progam analysis which isn't done.

That doesn’t matter.

> This breaks down with mutation, especially atomics, which are allowed as struct fields.

Not true at all. First, the compiler could refrain from doing this sort of code generation on fields with atomics (or any kind of mutable cell). Second, the object could be misaligned in some local contexts sometimes but references passed to functions could be always properly aligned. So a RefCell or atomic could still be copied or moved out and mutated, then moved back in, when the object is known not to have any references.

In general, this is close to reasonable code generation — a local struct could have some of its parts in registers. Its parts might be in noncontiguous stack locations. A language spec needs to specify that a field can be referenced or accessed via its pointer. It might also distinguish this from an alignment guarantee.

[Ericson2314]

If the compiler is so omnicient, then you should just be able to take the pointer to the field in the unsafe struct too!

Surely such a genius compiler can see "oh, they took a field reference, better make sure that field is aligned" whether the reference is a safe one or not!

[DSMan195276]

> That would be whole-progam analysis which isn't done.

Yet.