samhh
Unit newtype
Does anyone care about this? So we could do away with null/undefined entirely.
It brings it more in line with Purescript. It makes effect only monads more clear.
When I was starting out with fp-ts designing some API's, I didn't realise that we could use chainFirst with an effect monad to consume the effect but keep the result.
I like the idea and I'd use it.
Would it be a newtype as defined by newtype-ts or just a type alias?
I'd be inclined towards a newtype. It's too easy to mistakenly use or mix with your alias' underlying type, the same reason I've avoided branded types from io-ts. The trade-off, as with newtypes vs branded types, is the additional verbosity.
Assuming we are using monadic composition, the trade off isn't too bad. We can treat it just like a type, because we don't need to unwrap it at all because we do not consume the return value.
Thought about this a bit more.
I'm thinking this isn't something that a downstream library can really do - it wouldn't even be compatible with fp-ts which uses void, which is in effect undefined.
An alternative may be to export a constant somewhere called unit that would serve the same purpose, but would actually just be undefined. Notably fp-ts exports constVoid.