I definitely support the need for tooling like this. Whether or not it should be part of this library I can't say – for me, a standalone library works just as well and might allow to solve for different trade-offs.

There are some libraries that work well with fp-ts:

• Morphic
• ts-adt
• ts-pattern

And now yours, which is nice and simple – thanks for that!

Thanks for sharing those links! I wasn't aware of these libraries.

NB there's also sum-types.

I really like the idea of having a module to help with this - having to open a block for a case statement often looks out of place and gets on my nerves.

Some of my thoughts on the advantages and disadvantages of Variant (or equivalent) being part of fp-ts:

On the one hand I'm not sure that it fits in fp-ts since there's something slightly different about it as it doesn't follow the pattern of other modules. Also with variants not being native to typescript, it is harder to agree on a canonical way to implement them.

On the other hand, things that make me think it makes sense in fp-ts:

• Variant is dual to Record which does have a module in fp-ts, so it is at the same "level"
• Since some way of building variants is core to functional programming, it would be good to have a consistent "default" approach
• If Variant was in fp-ts, the encoders and decoders could be in io-ts without needing a separate binding library.

Variant is dual to Record which does have a module in fp-ts, so it is at the same "level"

I wouldn't necessarily semantically agree. There are multiple modules that represent product types, for example also Tuple and Map. Duals therefore might be specific sums such as Option and Either. This is a different level of abstraction beneath the aforementioned.