m4b

Hi @elpiel yea this seems like a pretty cool idea! I will note I'm worried it's turning into a kind of serialization format, but your usecase seems reasonable; especially with...

So looking at your Feature enum, it carries data. To summarize, hopefully correctly, it looks like effectively you check for tag, then if it matches known lookup-table of tags, then...

> Regarding this part. It might be sensible to stick to how Rust handles this. Even if you don't specify the value `Foo = 1`, Rust will automatically assign them...

I didn't see anything about it being stable, though I suppose the reference makes it so? And from link: > Under the default representation, the specified discriminant is interpreted as...

In any event, we could just by fiat make the un-explicitly tagged variants behave similar/identical to the reference posted (auto-incrementing +1 from last variant), for the derive serialization format of...

Also this brings up question of what size the tag should be serialized as; e.g., in example above, we have: ```rust #[repr(u16)] enum Foo { Bar, Baz } ``` I...

Yes it's possible, and will have the ambiguous behavior in the case of `pread` as you describe. I haven't thought much about whether I want it to be possible or...

Yea so generally it's not a very big deal; i did run into this when i was pwriting very large C structs, and it caused stack overflows, but this is...

That being said, I do think pwriting references is generally just a good idea, but not sure if we can find a hero to push it through; there were some...

@zicklag yup, your question is precisely what scroll was designed for; e.g., one original usecase was reading the Nth elf sym entries out of an array of `sizeof::() * nentries`,...