@bstrie:
It also be worthwhile adding a lint that warns if a struct without a #[repr(…)] is used in an unsafe cast, or passed to an extern function.
While it makes sense to lint for transmutes, because this invokes explicitly undefined behaviour, it makes less sense to lint if you pass a pointer to a struct with undefined repr to an extern function, as this is completely legitimate in the “callback” use case, where you pass a function pointer and a data pointer, and the function behind the pointer then gets gets called if something happens, with the data pointer being given to it as well.
Its just inconsistent IMO to say that one should revert the reorder PR because it may cause headaches for unsafe users of rust, but the same time to reject lints, because unsafe users “know what they are doing”. Also, if no lint is done at all, nobody will find out about their errors, and after one release cycle nothing is gained, is there? Not everyone reads the blog, and even if they do, should they really have to manually check all of their uses of repr?
@nikomatsakis
I think it would make sense to say that the layout of two structs whose fields have the same types ought to be identical (even if it is not specified).
I don’t think this follows from RFC 79 at all. E.g. this rustc issue proposes to randomize layout on debug builds, and seems to not conflict RFC 79, does it? If true randomisation is done though, fields with same types won’t have identical layout.
Also, saying “these things are identical, even though its not specified” is enshrining of undefined behaviour, and I think not something that should be promoted in any way, even in unsafe code.