Recursive and unsized enums

[tomaka]

It is currently forbidden to have this enum, because it is recursive:

enum Sequence<T> {
    Element { value: T, next: Sequence<T> },
    End
}

However in theory we could accept it by making Sequence unsized.

[glaebhoerl]

I think this is a really cool idea, if it can work (I don't momentarily see any reason why it couldn't, but I haven't thought very hard). Reminds me a bit of serialization formats where you have a flat stream of bytes with tags to indicate what comes next.

[ftxqxd]

It could be a little tricky to define how to construct one of these. A similar instance of the same problem exists today: it’s valid to to define a struct whose last field is a non-type-parameter unsized type…

struct Dst {
    x: [u8],
}

…but it’s basically impossible to construct one of these, because there’s no Sized equivalent to coerce from. I believe this proposal suffers from the same problem. The obvious solution would be to somehow allow unsized types in struct initialisers, but I’m not sure about how that would work in practice.

[Kimundi]

@P1start: Afaik @eddyb has a few ideas how to make that work.

[eddyb]

@P1start you would only allow it in an in-place context (&expr, box expr, in place { expr }) and then drag around enough context to save the extra information after (while?) writing the data.
Though panics might be tricky, it should still be possible.

[ticki]

I think this is really a cool idea, and is needed for the sake of consistency.

[serprex]

A useful extension of this is that an unsized enum which is non recursive could also be useful for taking up less space (consider enum BigOrSmall { A([u8; 2000]), B([u16; 10])}). Perhaps a #[repr(unsized)]

[tupshin]

I'll just weigh in in favor of this given my internals question where I unexpectedly ran into this same limitation.

[burdges]

There are discussions elsewhere about doing match on "artificial" enums, so another idea might be a trait

trait Match {
    type MatchEnum;
    fn run_match(&self) -> MatchEnum;
    fn run_match_mut(&mut self) -> MatchEnum;
}

so that if impl Match for FakeEnum exists then match fake_enum { .. } becomes match run_match(&fake_enum) { .. } or the mut version depending upon the patterns.

Assuming the trait fields RFC, there is a version with nicer borrowing semantics

trait Match {
    type MatchEnum;
    type EnumField;
    target: EnumField;
    fn run_match(&EnumField) -> MatchEnum;
    fn run_match_mut(&mut EnumField) -> MatchEnum;
}

where match fake_enum { .. } becomes match run_match(&fake_enum.target) { .. }.

We can maybe do the recursive unwrapping these describe using this approach like

struct Sequence<T>([T]);

enum SequenceEnum<T> {
    Element(pub T, &Sequence<T>),
    End
}

impl<T> Match for Sequence<T> {
    type MatchEnum = SequenceEnum<T>;
    fn run_match(&EnumField) -> MatchEnum {
        if self.0.len() > 0 { Element(self.0[0],Sequence<T>(&self.0[1])) else { End }
    }
}

except with lifetimes and unsafety around the borrowing of self.0. And maybe even an explicit length field if [T] lacks that.

All this looks less ergonomic of course, but you could maybe fix that with macros somehow. And it's definitely something lower-level developers run into frequently.

I donno if this approach might place less nicely with future schemes for type-level numerics though.

[RReverser]

To bump this thread: now that we have enums with well-defined memory layout such as repr(u8), repr(C) (ping @eddyb), etc., could we allow at least such enums to contain unsized data as last item of enum payload?

Then it would be possible at least for an unsafe code to construct such enums using same techniques as for any other structs (which such enum is equivalent to), and for other safe code to use it.

[eddyb]

@RReverser It helps with the optimization problem, but you still have the issue of the metadata not always being valid, and you also need to read from behind the data pointer to determine the active variant to get e.g. the alignment of the enum, which is needed for an operation like computing the true field offset in a type having that enum as a field (e.g. &pair.1 on (u8, Enum)).

I forget what we did for unions, did we just ban unsized unions? (cc @RalfJung)

[RustyYato]

@eddyb Unsized unions are in fact banned, playground.

[RReverser]

you also need to read from behind the data pointer to determine the active variant to get e.g. the alignment of the enum

Hmm. Isn't that the case for any unsized data structures anyway? E.g. you need to read from behind the data pointer to get alignment of a struct ending with a dyn Trait.

[eddyb]

E.g. you need to read from behind the data pointer to get alignment of a struct ending with a dyn Trait.

No, the reference/pointer to the struct contains the data pointer and the vtable pointer, there's nothing behind the data pointer that's not in a version of the struct where the dyn Trait is replaced by the concrete type (this is how unsizing works after all).