Hacker News Reader

Comment by GrumpySloth | Hacker News Reader

I agree with Rich Hickey here and I think this is a flaw of sum types compared to union types. If Option<T> was a union type, T would be a subtype of Option<T> and those changes wouldn't be breaking. When writing Rust, I find myself repeatedly writing implementations of the From trait for enums, just because most of the time I actually want union types, not sum types. I think sum types should be built on top of union types by combining union types with a "lexically-scoped newtype", if that makes sense (i.e. they wouldn't be built in, they would be the result of two orthogonal features, while allowing for other combinations as well).

Edit: another nice consequence of this design would be None being its own type, which can be transparently converted to an Option<T> for any T, allowing for type inference to go in only one direction, while still avoiding the boilerplate of Option<T>::None. Unidirectional type inference would make for more intelligible compiler errors. Full Hindley-Milner can get confusing.

View on HN

Union types are horrendous in practice because they're non-compositional. None|T is usually disjoint except when it isn't, and it's really easy to forget that case and fail to test it properly.

Having used Scala extensively, None as its own type is very much a mistake; it's not a type that you ever want and it only serves to get in the way.

What does it mean for None|T to be disjoint?

"If it's None then it's not T". It's very natural to write code that handles the case where the value is None, handles the case where the value is T, but subtly malfunctions if T can be None (e.g. you might write a cache and use None to represent the value not being present in the cache - but then your cache silently fails to cache if the thing you were caching returns None).

How is it natural to write code like that?

If it's None, don't put it in the cache. If T is None, don't put it in the cache.

if (typeof input != None) putInCache(input)

> If it's None, don't put it in the cache. If T is None, don't put it in the cache.

> if (typeof input != None) putInCache(input)

Exactly, now you've just written exactly the bug I was talking about.

If T is int|None, then None|T can't distinguish between None and T(None), whereas None|Some(T) can distinguish between None and Some(T(None)).

It seems like the issue then is that int can be nullable. The solution is to make int an int. You cannot assign None to int.

I'm not an expert on programming languages, but asaik this is how typescript operates

That's not quite what the parent is trying to say. Assume that int is not None. Create a type called T that is int|None - a term of type T can be an int, or it can be None.

Now have a function whose argument is T|None. Substitute in the definition of T and you get (int|None)|None. If the function's argument is None, what does that mean? Was it given a T that happened to be None, or was it not given a T? Nobody knows.

> Was it given a T that happened to be None, or was it not given a T?

Hmm. It _feels_ like a function shouldn't ever need to differentiate between "what the caller thinks it has" (that is - being passed a "T-which-is-None" should have the same significance as being passed a "None"), but I'm not confident claiming that would ever be the case.

Consider an expensive computation that may have no answer, and so it returns (after some heavy processing) "int|None".

Also consider a cache lookup function that takes some key and returns a generic T|None for T the type of cache entries, with None signifying the key was not found.

Both are, on their own, pretty reasonable things to have.

If you are using union types and you put the results of your expensive computation into your cache, you will not be able to tell when you've done an expensive computation for some key and got a None result, or when you haven't got a result in the cache for that key.

You can have both union types and sum types (imo ideally), or in this case can easily choose to represent the result of the expensive computation in a more reasonable/descriptive way.

Perhaps the more reasonable/descriptive way to represent the potentially no-value result of the computation is with a sum type, not a union type?

> If you are using union types and you put the results of your expensive computation into your cache, you will not be able to tell when you've done an expensive computation for some key and got a None result, or when you haven't got a result in the cache for that key

This is certainly an issue, but that's an issue for the _overall system_ of a cache which stores T. My claim wasn't that "Union types that Union with None can never cause issues", but rather that, for a function whose argument is `(int|None)|None`, there shouldn't ever be any different behaviour _of that function_ between "passed a T (int|None), which was None", and "passed a None (not a T)". The function itself should still behave the same way.

You're right, of course, that _returning_ an (int|None), where "None" might mean "the answer is definitively known to be None" or might mean "the answer is unknown, and that is represented as None" can lead to unnecessary recomputation - but that's an issue of return types, not of parameter types.

One function's return value is another function's parameter. If the overall system has a bug, that's a problem, and I don't see any value in trying to quibble about whether it's a bug in the caller or the callee.

> I don't see any value in trying to quibble about whether it's a bug in the caller or the callee.

Right, neither do I - like I said, "that's an issue for the _overall system_ of a cache which stores T.". The bug is that a given type (None) has different meanings to different components of the system, and this bug only arises _because_ "One function's return value is [being passed, directly, without any interpretation, as ] another function's parameter". If the type signatures were changed so that interpretation was required - so that "the answer is None" could be distinguished from "I don't have an answer" - then the bug in the overall system goes away.

> this bug only arises _because_ "One function's return value is [being passed, directly, without any interpretation, as ] another function's parameter".

Which is the normal way of programming. If you can't safely compose functions without adding an extra layer of interpretation between them, programming becomes much harder.

> If the type signatures were changed so that interpretation was required - so that "the answer is None" could be distinguished from "I don't have an answer" - then the bug in the overall system goes away.

Which is something that using sum types rather than union types achieves by default. Wherever you want to localise the problem, union types add a big, easy class of ways to shoot yourself in the foot that just aren't there if you use sum types.

It is useful to differentiate this, though. Consider a datatype of map with values of type T. The function to return value for a key returns None when the key is not in the map, but what if the key is in the map, but the actual value is None? IIRC Lisp has a workaround but it requires special code to handle maps that can have None as values.

As the other posters have said, it (automatically flattening the Maybe monad) is non-composable and should be considered a bad language design, like it was a bad idea to automatically flatten lists in Perl.

That's why in python that raises a KeyError, or if you use explicitly .get() you can specify anything as your default value.

It's probably subjective, but I don't see the need to wrap your code in a try/except block as an improvement over an optional sum type, and I really don't see the use of a magic value to indicate no value as an improvement over anything.

If it's not a try it's an if... you still need to handle the case where the key wasn't present and figure something out.

Which is why you end up with the painful

    sentinel = object()
    value = dictionary.get(key, sentinel)
    if(value == sentinel) ...

Which, sure, it works, but it's working around a problem that didn't need to exist in the first place. Why not just have Option work the way you expect, and be able to contain None the same way as it can contain any other value?

Well no, just handle KeyError :D

If you do that you still have the same problem, although the conditions for triggering it are narrower - you can't tell the difference between "your" KeyError and a KeyError from the callback you were passed.

Arguably, composing/depending on the composability of optional values is also a code smell. A Some(Some(None)) may be occasionally okay, but it is almost always better represented by an explicit type. Also, clojure can better express these in-between states, as demonstrated by the very good talk (I swear Hickey always sells me on Clojure.. I really should write something more serious in it)

Let's try this in python…

    >>> T = int|None
    >>> T|None
    int | None

Yep, quite simply this is solved flattening the unions and removing duplicates :)

Yes, that is the problem, imagine you might write a cache and use None to represent the value not being present in the cache - but then your cache silently fails to cache if the thing you were caching returns None

As I already wrote in a different comment, KeyError and None aren't the same.

That’s not “solved”, that’s highlighting what the problem is.

I don't think you should write code where it makes a difference if the None came from a T that happened to be None or from a None.

Why would you ever use T | None otherwise? As far as I can see the only reason to ever use T | None is because you want to write code that does one thing if it's a None and another thing if it's a T. Having it do the other thing if that T happens to be None makes no more sense than having it do the other thing if that T happens to be 5; at best it might work by accident, more likely it will be a subtle bug.

IF T is int|None, then None|T is None|int (and int|None), it's just a logical union of all possible values. You're complaining against issues of some weird Rust-enum-wrapper-like unions, which is exactly a problem proper unions types resolve.

> IF T is int|None, then None|T is None|int (and int|None), it's just a logical union of all possible values.

Which is confusing and introduces subtle bugs. It makes it impossible to reason about any part of the code in isolation, because you can't understand the behaviour of None|T unless you know what T is.

I think it’s only confusing if you use None as a _magic value_ with a meaning dependent on context. Like if you use -1 as a magic value of an int which means not a negative one (which you can do arithmetics on) but as “infinity” or “default value” or “use alternative method of calculation instead”. I think it is known that magic int values always come back to bite you later.

Same with None. None means “absent value”. If you use it like that, no confusion at all. Absent value or int is absent value or int. However, if in some places None means “absent value”, in others “error value”, in others “infinity”, in others “empty collection”—due to programmer’s laziness instead of using proper types, then _surely_ it will be impossible to reason. But not due to union types, I think.

> I think it’s only confusing if you use None as a _magic value_ with a meaning dependent on context.

Which is essentially every use of None? Like, the whole point of an option type, an X | None, is that None is not an X, and means something different.

> I think it is known that magic int values always come back to bite you later.

But the reason a magic int is a problem is because it's also a valid value. If you use -1 as a magic value, you will get confused because you can't tell whether it was whatever magic meaning you meant or the actual value -1. The whole point of using int | None is to avoid that problem, because None is never a valid int. Unfortunately if you have inclusive unions then that breaks down - you use T | None because None is never a valid T, but then if you try to use that with T = int | None, whoops.

> Same with None. None means “absent value”. If you use it like that, no confusion at all. Absent value or int is absent value or int.

What does that mean? I don't think there's any universal notion of "absent" that applies to every function in a single program, much less every program.

What None means is context dependent, sure, but that's fine as long as that context is local; after all, what e.g. 3 means in your program is also context dependent (maybe it means "3 users" or "position 3 in the array" or "file not found"). If you have proper nesting options, then maybe you'll compose together three layers and in the end you have some value where None means "not cached" and Some(None) means "error computing" and Some(Some(None)) means "empty collection" - but that's absolutely fine, each layer knows how to handle its own option and knows what None means in that context. The problem only comes when you have union types, because then you can't compose your layers without them interfering with each other.

> Like, the whole point of an option type, an X | None, is that None is not an X, and means something different.

Absolutely not! X|None does not mean X is never None. It's just a logical union (∪) from school. In this case it means "all possible values of X and also None if it was not in X".

For example, a function may take something like "Indexable<T> | Iterable<T>", and it is fine if it is passed Vector<T> which is _both_ Indexable<T> and Iterable<T>, the sets are not disjoint.

I think this is the root of our mutual misunderstanding.

> I don't think there's any universal notion of "absent" that applies to every function in a single program, much less every program.

I agree it's sometimes hard to maintain the same semantics over a codebase, but that's because software architecture work is hard.

Number 5 should mean approximately the same over the entire codebase, and for sure programmers will find a way for it to mean different things in different parts of the code, but that's what makes it a sloppy code that is difficult to maintain!

Similarly, if None means different things in different parts of a program, that's not a fault of mathematical logic or union types, that's just sloppy programming!

> Absolutely not! X|None does not mean X is never None. It's just a logical union (∪) from school. In this case it means "all possible values of X and also None if it was not in X".

Types are not sets, and thinking of them as sets will lead you astray.

> For example, a function may take something like "Indexable<T> | Iterable<T>", and it is fine if it is passed Vector<T> which is _both_ Indexable<T> and Iterable<T>, the sets are not disjoint.

Only because you don't care whether Vector<T> is processed as an Indexable<T> or an Iterable<T> - which is because you know that it implements both in a way that's consistent with each other, which is because you know there's a relationship between those two interfaces. But that kind of relationship ought to be expressed in the type system (in this case Indexable<T> should probably be a subtype of Iterable<T>), at which point you don't need to use a union at all.

The key use case for a union U | T is when the two types U and T are unrelated. And in that case, if you passed a type that happened to implement both U and T, you would very much care about whether it was processed as a U or as a T.

> I agree it's sometimes hard to maintain the same semantics over a codebase, but that's because software architecture work is hard.

> Number 5 should mean approximately the same over the entire codebase, and for sure programmers will find a way for it to mean different things in different parts of the code, but that's what makes it a sloppy code that is difficult to maintain!

> Similarly, if None means different things in different parts of a program, that's not a fault of mathematical logic or union types, that's just sloppy programming!

A codebase has to work up from the generic to the specific. Ultimately programming is the art of translating a business problem into a bunch of 1s and 0s, it would be absurd to demand that every 1 or 0 has the same semantics everywhere in your program. Just as at the very low levels you have code that interprets a bitpattern as a number or a character or an enumeration, at a slightly higher level you'll have code that interprets a collection as meaning exclude/exclude/transform or a value as meaning target/default/.... Particularly in library code, you don't necessarily know what the objective semantics of the values you're working on are. And all that's fine and normal - for most code, the internals of the value you're working on are and should be a black box - e.g. a sort function doesn't and shouldn't know or care whether the values it's sorting are numbers or strings, or whether one string is alphabetically before or after another - all it knows is that it has a collection and a way to compare elements of that collection. You should be able to use the same sort function to sort a collection forward that value withor in reverse, even though those are the exact opposite of each other.

It only becomes a problem if you mix up your layers - e.g. if you somehow pass a bitpattern that was meant to represent a number to a function that thinks it was meant to represent a string, or if your sort function confuses the magic value that was returned from the comparator with one of the values it was meant to be sorting. That's not (just) sloppy programming, it's poor language design, because you shouldn't even be able to make that kind of mistake.

Would union types be manageable if you only use them with concrete types rather than generic or inferred ones, or is it too easy to accidentally refactor a None into one of the cases (possibly hidden behind a typedef)?

A feature you can't use with generic types is pretty useless, frankly. So "manageable" yes, but the cure is worse than the disease.

I wouldn't say non-generic union types are useless; in fact the vast majority of sum or union types I write in application code (not libraries) are a combination of two or more concrete types, rather than generic ones.

Wait so in Rust you can’t have an Option<Option<T>>? That’s really bad!

In Rust you can, in Python an Optional[Optional[int]] is the same as an Optional[int].

You can have this, I’ve used it in Rust before.

You can, because Rust doesn’t support first class Union, and uses ADTs. Something like Typescript allows you to write “(T | null) | null)” but that is not the same thing as a double-Option’d type.

Rust actually does have an untagged union type, but it generally requires some unsafe to use it, doesn't seem to get much use beyond c/ffi.

It was added specifically for c/ffi, so this is cool.

but the untagged union is still an aggregate at the type level right? Your data is a union at runtime, but at the type level it's a distinct thing, yeah? TS in particular is offering bespoke anonymous unions, which is a different sort of beast.

Of course, rust being nominally typed it is a distinct thing, while TS is structural. But that aspect should affect much more than just unions, (that said I personally know very little about typescript so talk my opinions here with a grain of salt).

> Wait so in Rust you can’t have an Option<Option<T>>?

You can, Rust has sum types rather than union types.

> That’s really bad!

I agree, but some people seem to like union types for some reason.

Not sure I follow your argument, but I use union types extensively in TypeScript and I don't think they're horrendous at all.

E.g. it's very common to define a helper type like

    type Maybe<T> = null | undefined | T

and then with TypeScript's flow analysis I can easily determine when it's safe to call properties on a value, e.g.

    const foo: Maybe<Foo> = ...
    if (foo) {
        // Typescript now guarantees foo is not null or undefined
        // thus it's a Foo, so I can call any Foo methods on it
        foo.bar();
    }

> Not sure I follow your argument, but I use union types extensively in TypeScript and I don't think they're horrendous at all.

Have you ever used a language with a good implementation of sum types?

> and then with TypeScript's flow analysis I can easily determine when it's safe to call properties on a value

The problem isn't calling methods on null or undefined. The problem is when the value is null or undefined, but not for the reason you think (e.g. you think your code set it to null, but actually the generic code you called came back with null: T), and so you mix up the semantics.

Not the parent, but I have used Standard ML, OCaml, Scala and Swift, and I like union types as well. They are strictly more powerful than sum types. If I want to create an Option type such that Option<Option<T>> = Option<T>, then that's possible. With sum types only, it is not. Yes, this gives you Option<T> = T in situations where T = Option<S>. If I want to have a sum type, then I can just create a distinguishing "kind" field, as you do in TypeScript.

The argument against union types would be, that they are an advanced feature compared to sum types, and sum types are simpler to use right. The argument against sum types is that they are moving the role of types from descriptive to prescriptive, and that is what leads to the problem Hickey is pointing out.

While I get what you're referring to, the issue of Typescript getting this mixed up is not a real issue.

Why? If you write a function that takes T | null and returns T, then you're going to need to filter out your null.

Now, Typescript isn't safe, so you can have f: (T | null) -> T and give it a (null | null) and its return will indeed be null (at least at the moment, see [0]).

But your function's type guards will, at one point, filter out the null case. You might try doing this through some assertion, but if you do the runtime check, it will in fact blow up at runtime.

So Typescript will allow invalid code, but if you are actually doing type assertions correctly you'll get a runtime error at the "type narrowing" step. Worse than static verification of course, but better than carrying around a null that you think is not null.

Anyways, yeah, the conclusion is that in TS at least, T | null narrowing to T doesn't mean that T is not null. TS is at least smart enough to handle that.

[0]: https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABGO...

Yes, it is an issue, but not for the reasons you think. For example, take these two APIs:

    // returns null if post doesn't exist
    async function loadPost(id: string): Promise<Post | null>;

    interface ResourceState<T> {
        // null if no data has been loaded yet
        data: T | null;
    }
    function createResource<T>(load: Promise<T>): Observable<ResourceState<T>>;

Both are largely designed to fit together (`createResource(loadPost(id))`), but if you do then you now have no idea whether `data` is null because the post couldn't be found, or because it's still being loaded. You would either have to use different nulls (null vs undefined) or have `ResourceState` box T somehow.

§um types are safe from this because they can distinguish between `None` and `Some(None)`.

Right, I agree with that. I think in practice this is largely circumvented by ad-hocing tagged unions in these cases.

Higher level, I think that it's fairly rare to see Optionals outside of the _very_ basic cases, and downstream of that you're actually not flinging around nulls or undefined as data. Instead everyone reaches for a kind attribute. Especially in cases like you're talking about (where there's this notion of not finding something, but also this notion of something still loading).

Not to say the distinction doesn't matter, but TS feels well designed in the sense that all of its unsafety is in places that end up not coming up in many "normal" codebases

> But your function's type guards will, at one point, filter out the null case. You might try doing this through some assertion, but if you do the runtime check, it will in fact blow up at runtime.

The problem is the other side: if you filter out null then you accidentally end up filtering out part of the T case as well, when you only meant to filter out the case that was not T.

More generally, I submit that if you're doing your types properly you never want to collapse T|S into something different from a sum type. You have code that handles T which you expect to handle the cases that come from the code that yields T. You have code that handles S which you expect to handle the cases that come from the code that yields S. When a T turns out to be an S, or vice versa, that can only ever be a nasty surprise, or at best some code that works by accident.

Should T | null narrow to T | never inside a !== check ?

I'm not sure what this would imply.

On the other hand, explicitly writing coercions from T to Option<T> gets tiring real fast. I'm sure it should be possible to design a typing+coercion algorithm that automatically coerces `x` into `Some(x)` in 99% of the cases that are actually unambiguous (either due to the type of `x` being known not to be an option or due to parametricity), which would be the best of both worlds.

What happens in the following case?

    const foo: Maybe<boolean> = false;

It seems to me that your code wouldn't behave they way you'd expect.

That’s because of the "truthy-ish" nonsense mess inherited from JavaScript.

You could say the same with 0, "", NaN.

That being said, I wonder what was the logic behind the decision to implement that.

Coercing nullishness/undefined-ness to false arises from languages like C. It is an unfortunate footgun, but not what most people think of when they think of Javascript's coercion weirdnesses.

Typescript supports this because it is a strict superset of Javascript.

They certainly could have made TS strict mode complain about it though.

If you want to cover this particularly case, strict-boolean-expressions in tslint should catch it.

That being said, I agree it's an unfortunate footgun and think tsc should yell at you for using non-boolean types in conditionals if strict is on.

I use this crate to avoid the boilerplate https://jeltef.github.io/derive_more/derive_more/from.html

Whenever i design a lang, i just give option semantics to types of the form `x|none`

> which can be transparently converted to an Option<T> for any T, allowing for type inference to go in only one direction, while still avoiding the boilerplate of Option<T>::None

You don't need to qualify the None, the following works:

    fn foo<T>(x: T) -> Option<T> {
        None
    }

Yes. That's thanks to Hindley-Milner type inference which makes the compiler infer which None you mean. But in longer code snippets full Hindley-Milner type inference can cause hard-to-understand type errors. Here specifically the compiler infers the type of a value in your function body based on the type of the function it belongs to, which is in the opposite direction than what a programmer typically thinks in. It leads to spooky actions at a distance.

> It leads to spooky actions at a distance.

I'll disagree on "spooky". If the type is ambiguous, the code will fail to compile. Contrapositively, that means that if the code compiles, the types aren't ambiguous. I find bidirectional type inference to be absolutely lovely (or at least Rust's implementation of it), and I wouldn't give it up.

It's actually not. There's simply a 'use Option::{None, Some}' built-in to make them easier to work with.

The GP is referencing cases where inference can't figure out what the T is in Option::<T>::None. This can happen in the body of a closure without an explicit return type, for example. To solve it you have to specify the type either earlier in a place that helps inference (in the example, add a return type) or in the expression, like None::<()>.

Yeah sorry I apparently can't read, it was pretty obvious. Thanks.

As another poster said, None is in the prelude. It’s been explicitly imported, just… implicitly so. Other than that, Rust places strong emphasis on function signatures. They override everything else, such as inferred return types from the function body. This is to ease composition and reading (as far as I remember). That is to say, in Rust it is quite natural to refer back to the function definition, potentially to let it do inference heavy lifting, or work with the question mark operator. It doesn’t feel the wrong way.

> But in longer code snippets full Hindley-Milner type inference can cause hard-to-understand type errors.

I would love to see examples of this. We've gotten much better on this front over the years, but I'm sure there are plenty of cases yet to be addressed.

The "problem" with improving error messages is that the common and easy cases are addressed early, leaving only the uncommon and difficult to address left after a while, and people get used to the understandable errors which leaves them baffled when they encounter one that isn't.

> Unidirectional type inference would make for more intelligible compiler errors. Full Hindley-Milner can get confusing.

Bidirectional type checking has good error messages and a very intuitive implementation.

Rather than just taking a statement from OP and stating the opposite, can you elaborate on why you disagree with them?

My personal experience has been very much in line with OP's: nonlocal type inference (in Rust specifically) frequently makes code hard to modify because a change can cause inference to fail in unexpected ways and places. Local inference doesn't have the same tendency.

They didn't state the opposite, bidirectional typing rules are a technique to describe a type system, distinct from both Hindley-Milner's and simple "unidirectional" checking.

I'm using it for my personal lang project and I'm quite satisfied as well, it translates easily into code and interacts well with subtyping.

> most of the time I actually want union types, not sum types.

Really? This surprises me to the point that I'd like to ask what you are coding.

I'm having a very difficult time picturing "You have A|B|C|D and you send in an A and extract a D" (union type without tag). The only way to do that is to guarantee memory layouts, which is something Rust explicitly does not do.

What am I missing?

You're thinking about C unions, not union types. Union types behave more like unions in set theory. Sum types behave more like disjoint unions. In particular, if you have a union type A|B, then A is a subtype of A|B. If you have a sum type A+B, then A is not a subtype of A+B, because for A=B, A+B has two instances of A, i.e. A+A != A, so for each element you need to be able to distinguish which instance this element is from. Whereas with union types A|A = A. It doesn't mean that union types are as willy-nilly as unions in C. It just means that you can assign variables of type A to variables of type A|B without any ceremony. If you want to extract an A from A|B, you need to write a runtime check (just like match in Rust with sum types). It does mean though that you can assign a value of type B to a variable of type A+B and then extract an A, if that value was in the intersection of A and B.

I understand both the mechanics and the implementation. What I was asking for was the use case.

Making assignment easier and compile time at the cost of making access costlier and runtime seems like an unusual tradeoff. I'm very interested in the case that makes that worthwhile.

Transferring costs from compile time to runtime is pretty much the signature move of dynamic languages. If you already carry around type information and check it at runtime, why not just add union types? Your implicit conversion is zero cost at that point, after all.

Most of my enums are sums of types that don't have any intersection. You can think e.g. of a type Token that is a sum of Identifier, Number, etc. It's annoying to keep wrapping Identifier in Token, instead of just assigning. I solve that by writing generic functions that accept anything that implements the From trait, but it's still boilerplate all the same.

There is no shifting of cost from compile time to runtime, or slowing down access. Just like with sum types you're writing match clauses from time to time, with union types you do the same. If you need to inspect the discriminant, then you need to inspect the discriminant.

There is some runtime complexity here though.

With both enums and sum types, if you want to differentiate the types at runtime, you need to include a discriminant in order to be able to do that. Enums include that discriminant explicitly (that's what the `Token::Identifier(...)`/`Token::Number(...)` part represents). The memory layout for, say, a base identifier can consist only of the necessary fields for that identifies, but when it gets wrapped it will get an extra field that identifies which variant of the en it is.

With sum types you have two options:

* You always include a type tag directly in the representation (so a base identifier always has an extra byte or so of information with it). This is typically used in dynamic languages where the types are known at runtime anyway. I believe it's also the case in Java and I suspect other VM-based languages are similar. * You dynamically generate the enums at compile time (so a base identifier doesn't have a tag, but if it's used in a `Identifier | Number` union, then a tag for that specific union gets added in).

The problem with the first is that it adds unnecessary runtime cost, because now every instance of any type has extra information in it that probably isn't needed. The problem with the second is that the creation and unwrapping of enum values becomes implicit, and you'll probably need to juggle your discriminants around more. Say I gave a function of type Identifier | Number -> Boolean | Identifier | Number, then should the discriminants for the Identifier and Number cases stay the same? Or do we need to add extra code to munge the input discriminants into output discriminants? In the first case, this adds a lot of complexity to the compiler (and may not in the general case be possible), in the second case we have runtime performance issues.

This is, I think, the point that the previous poster was getting at. If you have implicit discriminators, this will have an implicit runtime cost that may not always be easy (or possible) to avoid. That is the value of explicitly wrapping types in enums - the runtime cost can be minimised, and the developer is always aware of where that runtime cost appears.

I’ve used C++ variants (from a couple of different libraries) a fair amount, and they are sort of union types, and I generally dislike it. The problem is that logically identifying the contents based on type is confusing and refactors poorly.

Suppose I have an Identifier or a Number or a StringLiteral. To work intelligently, this needs Identifier and StringLiteral to be disjoint. This isn’t just a type theory issue —- it’s a semantic issue. What is “foo”? Is it an Identifier or a StringLiteral? What happens when I add a Filename (for including/embedding files in the future)?

Logically, the fact that an Identifier is encoded by a particular type is a bit of an implementation detail, and a good type system will catch errors. It’s the fact that it’s an identifier — that is, it’s purpose — that matters for semantics and for understanding the code, and union types (and C++ variants, for the most part) are very bad at exposing this.

My issues with std::variant in C++ boil down to it being a runtime, not compile-time construct, and surprising interactions with implicit casts, especially in the case of primitive types. After that, unlike what I described about combining union types with lexically-scoped-newtypes, std::variant doesn't let you build sum types when you need them. You're stuck only with union types.

> What is “foo”? Is it an Identifier or a StringLiteral?

Normally, it's an identifier, since there are no quotes. If there is ambiguity about it, the lexical categories you're working with are ambiguous, which is a real issue. When designing a grammar, that should be avoided. Sadly, sometimes we're given a poor-quality grammar like in C, where some tokens can be interpreted both as headers and as string literals (but neither is a subset of the other) and can't do anything about it, but then you just need to decide which category you're going to assign to ambiguous cases (either one of two, or make a third one) and later you can disambiguate based on context. In any case, I don't consider it an issue of the tool, but an essential domain problem to be solved explicitly by the programmer.

>> What is “foo”? Is it an Identifier or a StringLiteral?

> Normally, it's an identifier, since there are no quotes.

Sorry, I was vague. I don't mean the sequence f o o in the input or the sequence " f o o ". I mean the string (String, str, whatever your language calls it) containing the three letters f o o, which is stored in a union type.

Sure, one can lexically-scoped-newtype it if the language supports it, but at that point, unless I'm missing something, it might as well be a sum type.

Reply on news.ycombinator.com