Pre-RFC: Explicit Opt-in OIBIT for truly POD data and safe transmutes

[cristicbz]

I will mention it as a important alternative in the RFC. Changing a type to non-Copy is a massive backcompat problem due to the change in the semantics of assignment and binding in general.

I think there are two important points which make me lean towards automatically applying to not making Reinterpret opt-in:

1. Adding a private field to a struct with all public members is already non-backcompat because you’re making the ‘constructor’ private: i.e. I won’t be able to write MyStruct { field1: 10, field2: "asdf" } anymore. Therefore, if you want to leave the door open to private fields, you’ll have to add a dummy private field e.g. _dummy: () anyway.
2. If you buy (1) and accept that a Public type has already commited to staying that way, then applying Reinterpret without explicit opt-in feels like a small leap: all the functions defined on a Reinterpret type could be manually implemented with safe code. They’re just fancy ways of setting the values of public fields.

That said, I’m sympathetic to backcompat worries, so, like I said, I’ll make sure this gets the right amount of space in the RFC.

[arcnmx]

Aha, finally read the whole thread. Looks like I re-implemented the same scheme suggested a few days ago! It’s still a bit messy but my current derive version is also up now: http://arcnmx.github.io/nue/nue_macros/

A few random comments, then…

• I’m for making the trait explicitly opt-in. I can’t imagine many situations where a type from an external crate needs to be mappable. I suppose newtypes aren’t a reasonable fallback though, without at least some sort of unsafe impl…
• In line with 1, requiring all members to be public doesn’t seem necessary as long as it’s opt-in only from the crate that defines the type.
• The repr requirement can be enforced with a #[derive(...)], though I do like the marker trait approach more. The language could really use some more marker traits!