y86-dev

@rustbot label +T-libs-api -T-libs

In ece8b0d I fixed the soundness hole [found by pitaj](https://internals.rust-lang.org/t/pre-rfc-field-projection/17383/51?u=y86-dev) in the internals thread. Sadly this is to the detriment of ergonomics, but I think keeping existing behavior the same...

> `Option` on the other hands feels a bit too "magic" (perhaps because that's not `#[repr(transparent)]` and incurs a hidden conversion which Rust otherwise avoids). To me there is no...

yes you can do ```rust struct Foo { bar: Bar, } struct Bar { a: usize } let data = UnsafeCell::new(...); let a: &UnsafeCell = unsafe { &*addr_of_mut!((*data.get()).bar.a).cast::() } ```...

The trait must also be `unsafe`. Because it is only allowed to do projections.

> The layout of T is not guaranteed to be the same as the layout of Option. The cost may neglible, and it may even be optimized out in most...

> My point there was that: (1) with the example of UnsafeCell, you might as well use unsafe for the rest too and (2) while it's very verbose in this...

I think for the beginning we are not going to support those. But conversion can only happen in one way, right? (so from fat => thin) So it might be...

There is also the big question of how we want pin projection to look like. [Here is a zulip post about that](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/ergonomic.20pin-projection/near/301414496)

@matthieu-m > but I am not at all convinced that making `.` more magical I have added a section about the possibility of adding a `~` operator. This was suggested...