Discuss RFC 2580 (Pointer metadata and vtable) about lang-team

[nikomatsakis]

@SimonSapin would you be interested in attending such a meeting, and any thoughts about who else should attend?

[rustonaut]

Edit: See discussions on the RFC RP instead.

I have one small thing about RFC 2580 which I think is a problem:

The way pointer thinning is done isn't very ergonomic, getting a thin pointer to the inner unsized value also requires unsafe code. I believe both should be doable without needing to write unsafe code. On the long run using custom DST types should preferably not be "magic" using pointer offsets and alignment fixing but easy to understand rust code.

E.g. if we have a thin pointer to a struct like struct Foo { f1: usize, f2: usize, dst: [u8] } we should still be able to access f1, f2 without unsafe code.

I know this makes this a bit more tricky as this likely would make Thin ptr. a language level thing instead of just a (core) library component.

E.g. something like foo: &Thin<Foo>, foo.f1: usize, foo.dst: &Thin<[u8]> and then we could have a fat pointer constructor which takes a *const Thin<T> instead of a *const () making it more type safe.

Through it's just the part about thin pointer which I think we could do better, the rest about getting metadata from fat pointers and creating new fat pointers and DynMetadata for trait object's seems all fine.

Through we should be aware that DynMetadata does two level of erasure: 1. the dyn type erasure and then 2. the erasure of what trait is left. By keeping the dyn Trait in some PhantomData we could later one extend it with vtable specific functionality. (i.e. DynMetadata<dyn Any>).

Lastly I would maybe remove some of the traits from the Pointee::Metadata bound, while all currently used metadata does fulfill the traits we might later one features which e.g. require non Send/Sync Metadata (e.g. dynamic VTables in thread local storage). But then all the features which would require it are so crazy that we probably don't want to support them anyway 😉

I have to apologize for not commenting earlier, I was basically close to offline for half a year and before wasn't aware of this RFC (or more concrete that it still get's updated after it got delayed 2 years ago).

[SimonSapin]

Thanks @nikomatsakis for getting this moving again. Yes I’d like to attend. I’m in UTC+2. I’m not sure who else should, maybe a few folks who commented the most on the RFC?

@rustonaut I think technical discussion about the proposal should likely stay within the RFC PR comment thread as long as that’s open. Do you mind reposting there?

[rustonaut]

Sure, I already planed to post there in the right sub-threads, just got a phone call 😄 [EDIT: done]

[KodrAus]

I'd be keen to attend ✋ But don't let my far-out timezone affect scheduling

[joshtriplett]

In today's lang meeting, @withoutboats volunteered to try to coordinate a design meeting for this.

[nikomatsakis]

This is now scheduled for Nov 4. We'll need some preparation work.

Sense for the meeting:

• Immediate desire is to be able to manipulate representation of trait objects
  • Summary of the RFC and what it propses
• But want to be forwards compatible with future developments like custom dst, dyn A + B, etc
  • Will therefore want a summary of some of those ideas and notes on how they interact

If folks can leave comments with notes on some of the future developments (e.g., pointers to RFCs, etc) that would be useful to help in preparing this document.

[nikomatsakis]

Minutes posted: https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2020-11-04-RFC-2580-and-custom-dst.md