Jacob Lifshay

proof of concept using `__instancecheck__`: https://godbolt.org/z/e1494MGzE

added matching to proof-of-concept: https://godbolt.org/z/v6aP4naMn

note that LLVM already implements this operation: [`llvm.memcpy.element.unordered.atomic` Intrinsic](https://llvm.org/docs/LangRef.html#llvm-memcpy-element-unordered-atomic-intrinsic) with an additional fence operation for acquire/release.

something that could work but not be technically correct is: compiler acquire fence unordered atomic memcpy compiler release fence those fences are no-ops at runtime, but prevent the compiler from...

> The unsized field of an unsized struct/tuple _does not have a fixed layout_, so `offset_of` makes no sense for such a field (not as a compile-time constant, anyway). But...

> > The unsized field may not have a fixed layout, but it often can have a fixed offset, thus offset_of! makes sense to have. > > e.g.: > >...

perhaps `Aligned` is a better name than `KnownAlignment`. for backward compatibility, `Sized: Aligned` and `T: ?Sized` implies `T: ?Sized + ?Aligned`

> > dyn types would have to be dyn MyTrait + KnownAlignment to be usable with offset_of!. > > That would not work -- `dyn MyTrait + KnownAlignment` implies that...

I also suggested having `Aligned` since it would allow `offset_of!` to work on struct fields that are slices/`str` (aligned but unsized): https://github.com/rust-lang/rfcs/pull/3308#issuecomment-1232875837 https://github.com/rust-lang/rfcs/pull/3308#issuecomment-1232880185

> I'd like to see some consideration on how this interacts with the pointer metadata APIs? In particular, it is being considered in [rust-lang/rust#81513](https://github.com/rust-lang/rust/issues/81513) to add `Thin` as a supertrait...