Tuple of (T, Seq<T>) or (T, IEnumerable<T>) could be used as Seq<T> / IEnumerable<T> using Cons semantics we could get some light-weight "non-empty" types.

[louthy]

Just another idea: If any tuple of (T, Seq<T>) or (T, IEnumerable<T>) could be used as Seq<T> / IEnumerable<T> using Cons semantics we could get some light-weight "non-empty" types.

I'm not sure whether this would work (implicit conversions). If yes then there should be a counter part for Match, i.e. match should give us the empty case and the tuple type above.

Originally posted by @StefanBertels in https://github.com/louthy/language-ext/issues/583#issuecomment-597029008

[StefanBertels]

Maybe having co-variance helps. I just want to drop a link here: https://stackoverflow.com/questions/59411397/what-makes-valuetuple-covariant

[StefanBertels]

Another though: Could/should collection types support deconstruction (to head + tail)? I'm not sure whether there are some usages of Deconstruct() already in there that conflict with this. Seq already has deconstruction, other IEnumerable types maybe can get it, too?

[louthy]

@StefanBertels https://github.com/louthy/language-ext/blob/master/LanguageExt.Core/DataTypes/Seq/Seq.cs#L80

[louthy]

Sorry, didn't fully read your comment! I'm not against adding it to other types, but Seq is explicitly something that supports Cons, so it makes sense there

[StefanBertels]

I have to withdraw my comment: having deconstruction is a good thing only for non-empty sequences. It will fail on empty sequences. Deconstruction on maybe-empty collections should be done in an explicit way, showing the problem: Lst<int>.ToHeadTailUnsafe() (or at least some UnsafeValueAccess extension).

But same thing is essentially true for Seq. I'm aware that Seq is often used with (head, tail) semantics but there are empty Seqs as well. In case we have a good (head,tail) solution based on tuples there might be some value in removing the "implicit" deconstruction for (maybe-empty) Seq. But I see that there is Head() for collections, too. Which will fail, too (without any "unsafe" mark).

[louthy]

Both Match and Case allow for explicit deconstruction.

It's not ideal for the deconstructor to exist, but as you pointed out, there's already precedence with Head.