>` to be safe to pass across ffi boundries as well as many other types.
---
### Author:  [@mcy](https://internals.rust-lang.org/u/mcy)
#### Post date: [April 8, 2019, 6:32pm UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/3 "2019-04-08T18:32:27Z")
I think you want to phrase this in terms of explicit "`ManuallyDrop` is `transparent`", instead of vague “ah yes same layout”. There’s a lot of layout niche optimizations, but we probably want to be very clear on exactly which are FFI-safe.
---
### Author:  [@mjbshaw](https://internals.rust-lang.org/u/mjbshaw)
#### Post date: [April 8, 2019, 6:49pm UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/4 "2019-04-08T18:49:15Z")
> [@RustyYato](#):
>
> `Option` isn’t special in any way, any enum that looks like `Option` has the same properties as `Option` .
Oh cool, I thought `Option` was the only one whitelisted for FFI usage, but indeed [custom enums work too](https://rust.godbolt.org/z/uSlVI5). In that case I'll revise my OP to include other types.
---
### Author:  [@RustyYato](https://internals.rust-lang.org/u/RustyYato)
#### Post date: [April 8, 2019, 8:01pm UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/5 "2019-04-08T20:01:02Z")
Yes, that is what I meant, I couldn’t think of a good qay to phrase it
---
### Author:  [@mjbshaw](https://internals.rust-lang.org/u/mjbshaw)
#### Post date: [April 8, 2019, 8:30pm UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/6 "2019-04-08T20:30:25Z")
> [@mcy](#):
>
> I think you want to phrase this in terms of explicit " `ManuallyDrop` is `transparent` ", instead of vague “ah yes same layout”.
That's more or less what I was trying to express. I revised my second bullet point to say "if `X` is a `struct` type that is `#[repr(transparent)]` and it’s underlying representation is `T`" in an attempt to clarify that. If there's a better way to express this, or if I should revise another part, let me know.
---
### Author:  [@dhm](https://internals.rust-lang.org/u/dhm)
#### Post date: [April 13, 2019, 8:23pm UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/7 "2019-04-13T20:23:21Z")
> [@mjbshaw](#):
>
> If there’s a better way to express this
I don't know if it is better, but `#[repr(transparent)]` `struct`s (and maybe unions) are _wrappers_ around an inner type; so I would say:
> If `W` is a `#[repr(transparent)]` wrapper around `T`, then ...
* * *
I would also add that although [undefined layouts w.r.t the type parameters seem to be a desirable feature](https://github.com/rust-lang/unsafe-code-guidelines/issues/35), what the OP's proposition shows is that there is also an interest in having `#[repr(transparent)]` lead to a "structurally equal" equivalence relation `≡`:
- for all types ``, we note `W → T` when `W` is a `#[repr(transparent)]` wrapper around `T`;
- we then note `≡` the transitive, reflexive and symmetric closure of `→`
With that in mind, it would be great if a type's properties w.r.t its type parameters remained the same modulo structural equality, such as the type's (enum-optimized) layout, which would solve the OP's legitimate request:
- for all types `,` and for all type constructors `F`, `T ≡ U ⇒ F ≡ F`
This would match most people's intuition about layout properties I think.
---
### Author:  [@gnzlbg](https://internals.rust-lang.org/u/gnzlbg)
#### Post date: [April 16, 2019, 8:09am UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/8 "2019-04-16T08:09:22Z")
If the only-thing you want to guarantee is that option-like `repr(X)` `enum`s have the same ABI as their non-ZST field, that could be a single RFC. Whether that should be guaranteed for `repr(Rust)`, or whether we want to allow `repr(transparent)` on these type of `enum`s, is up to the writer of the RFC to make a case for.
If this guarantee does not prevent any optimizations for `repr(Rust)` option-like enums (AFAICT it is actually an optimization), I think I’d prefer to just guarantee that for all of them. We want to guarantee that all “option-like `repr(Rust)` `union`s have the same layout and ABI than the only non-ZST `union` field” anyways, so this would go hand in hand with that.
OTOH, there is an RFC open about allowing `repr(transparent)` for option-like `union`s that’s in FCP. If that RFC is merged, then it would feel inconsistent to not be able to use `repr(transparent)` on option-like `enum`s as well for the exact same reasons given in that RFC (better error messages mostly).
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [July 15, 2019, 8:09am UTC](https://internals.rust-lang.org/t/options-ffi-safety-and-guarantees-for-abi-compatibility-with-nonnull-optimizations/9784/9 "2019-07-15T08:09:25Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.