Support for tuple structs and tagged enums

[vortexofdoom]

This is something that it seems like the inner guts of the proc macro could probably handle, but the syntax isn't quite there. Basically a way to determine what the descriminant bit(s) are directly while keeping access to the rest of the fields in an appropriate way.

This would make using bitfields as unions much simpler and ideally safer, as the enum discriminants could be matched against in a way that statically prevented the "inner" fields from being accessed in that way.

I don't know exactly how I'd want it annotated but I'm thinking of something like:

#[bitenum(u16)]
enum Foo {
    // If the MSB is zero, read the rest as a single 15 bit integer
    A(u15), // some way to denote the MSB specifically as 0,
    // Otherwise, read the remaining bits in chunks
    C { // some way to denote the MSB specifically as 1,
        /* other types adding up to 15 bits */
    }
}

Basically

This is not a pressing issue, as I know that you can have overlapping bit fields, but it could provide an ergonomic way to pattern match and would feel very "rusty".

The thing that might be neater to see (and could maybe accomplish the same goal) would be support for tuple struct syntax in general.

This would be harder since there are no named fields, but this is just a pie in the sky idea anyway.

[hecatia-elegua]

You know, there's arbitrary enum discriminants. Then we only need a way to tell how many bits the whole enum has and how many bits the discriminant has. Also, I imagine there are use-cases where the discriminant is saved somewhere else, not exactly above the value. How could we solve that as well? One idea I had was:

struct Bar {
   //either here
   #[discriminant_of(foo)]
   discr: u2,
   baz: u4,
   //or here
   #[discriminant(discr)]
   foo: Foo,
}

Which would only work if the field is at least in the same register. More generally, matching/enums/or-s are about branching and conditionals. In ARM for example, there exist register fields which are different based on some other far-off bool (or enum) value. So it might be more beneficial to do:

struct Qux {
   #[conditional]
   foo: Foo,
}

Which then means "this field could be any one of the variants in Foo, please pass in a discriminant". Haven't thought that through completely, though.

And yeah, no named fields means we'd have to annotate the whole tuple with all its ranges.