Field offsets

[Zoxc]

Rendered view

[huonw]

Where is the FieldType type introduced? (typo?)

[lilyball]

I'm assuming the Field parameter is supposed to be FieldType.

[huonw]

I don't understand this example. What is new doing with an FieldOffset object, and how does add work?

Can't this currently be achieved equally well with

let mut a = List::new();
let mut b = List::new();
a.add(&obj.list_a);
b.add(&obj.list_b);

?

[lilyball]

My understanding is @Zoxc's primary motivation here is to be able to build a linked list using internal storage instead of the more common external storage. The need for field offsets is so that way a single type can participate in multiple lists simultaneously (by providing multiple node-ptr fields).

[huonw]

Ah, so this is using the list_... fields as the backing pointers/information for the linked lists. This example would be very very much improved with more explanation.

[lilyball]

I just wrote a long comment on #174 about associated values in conjunction with field offsets that I think provides a potentially-compelling reason to have field offsets.

[bgamari]

@Zoxc for what it's worth here is a possible implementation of an intrusive linked list without needing field offsets. It does require a helper trait, but I think this trick should work for many cases where field offsets would be useful.

[huonw]

BTW, RFCs should not be rebased or amended; any changes should be made with new commits.

[Zoxc]

This should probably be postponed until #56 or something like that lands in order to provide greater motivation.

[brson]

I believe that the broad goal here is to provide better support for 'intrusive' data structures, which Rust is currently weak at. It's not clear that this is the design to solve that problem, and @pcwalton has some ideas for designing intrusive data structures without changing the language.

offsetof is certainly a potentially useful operator, and for that the keyword is already reserved.

Closing. Thank you.