Open samhh opened 2 years ago
These could return NonEmptyArray
as our sum types must always have at least one constructor. (Fun note: Apparently they needn't in Haskell, data X
is a valid declaration.)
Member<string>
(non-literal) allows {}
in enumerate
, making the function partial, however that's arguably reasonable in the sense that by not providing literals to Member
the library's contract has been violated.
It's a common use case to want to enumerate members of a sum type. This probably warrants inclusion in this library, but in what shape?
In Haskell, for all-nullary constructors, this might look something like this (GHCi):
I believe that whilst derived instances of
Enum
andBounded
have a predictable order with relation to the data type definition, this isn't guaranteed for all possible implementations nor would otherwise be unlawful.We have some helpers in Unsplash web with these type signatures and usages:
Unlike in Haskell, we can produce an enumeration provided an associated value for each constructor of a non-all-nullary sum type.
Because we've made the design decision to first and foremost define our sums at the type level, we don't know the tags at runtime except when provided by the consumer. In this case that means providing us with an array or object of tags. Sums of all-nullary constructors can benefit from a shorthand definition as above, however by moving from object keys to an array of keys we lose a uniqueness guarantee on the input. Additionally
ExactMatch
is required to ensure every key is present at least once.fp-ts has a Bounded typeclass, but no
Enum
, nor any helpers. Notably in fp-ts, unlike in Haskell,Bounded
is a subclass ofOrd
.