Besides hasKey + a separate getKey as a second step, we can also have an API that returns a tuple:
let (has, value) = dict[forKey: key]
if has { print("has value (potentially nil): \(value)") }
else { print("no value") }
It would be rare in practice, in the majority of cases normal subscript could be used.
This introduces a split source of truth, and opens the possibility for time-of-check to time-of-use bugs
This is similar to what C# did, except rather than return a tuple of two elements, their Dictionary.TryGet returns a bool that can be checked directly in an if statement (the value is returned from an out-paramter).
string value = "";
if (openWith.TryGetValue("tif", out value))
{
Console.WriteLine("For key = \"tif\", value = {0}.", value);
}
else
{
Console.WriteLine("Key = \"tif\" is not found.");
}
It's a matter of taste, but I think optionals better represent this concept in one convenient package, and lead to better syntax.
Anyway, to get back on track, I'm still interested in motivating examples for anonymous union times. The proposal of T | nil is a good one, but Optional<T> fills that role pretty reasonably, just using enums (and some special sugar, implicit optional promotion, etc., which I'll grant is a bit "magical")
Nested optionals also used to model the difference between "an error happened" and "the function returned nil" — but still it was decided to flatten the result.
Weird, pointlessly… do you have some evidence to back up such strong claims? (quirks specific to JS are not enough).
There are surely lots of examples, but I expect those to be much weaker, because they are either very specific or much more complicated than the (now) well established concept of optionality.
Swift decided to implement optionals using enums, that is what you are used to, and it most likely will stay that way forever.
But you could also claim that no one needs hammers, because stones are just fine to drive in nails.
Swift decided against union-like types, but its implementation of optionals needs big tweaks to mimic behavior which comes automatically with the union-approach.
Besides implicit optional promotion and SE-230, there is a class of issues due to the wrapping which is happening. I don't remember all cases of "sorry, optionals are not supported", but the most prominent might be that optional closures are always escaping (just because of the enum).
I think the really interesting question is "what is actually so terrible about anonymous union types that we should never get them?".
I think my motivation is slightly different than this pitch: What I want is really anonymous ad-hoc enums with lightweight syntax. Their cases would probably more often that not be without associated types at all.
But if we were to implement anonymous enums generally, associated values would naturally fall out from such a feature, and that it would imply a general solution to this pitch. It would also fill the gap in our table of supported types.
Just as anonymous structs (tuples) can have either labelled or unlabelled elements, I can envision a light weight syntax for inline enums with either named or unnamed cases. And that one could switch over it to extract values.
I would grab for this feature mostly when I need single-use enums as arguments to functions. Today I either have to create full-fledged enums that litter the module name space — or misuse optionals, use a combination of boolean flags or create a set of protocols — again littering the name space.
In short: This is useful the same way tuples are.
Exactly. I find tuples useful, thus I would find anonymous enums useful, it's as simple as that. Of course, one can make a case against the usage of tuples, that would also, dually, be a case against anonymous enums, but that's a different (but valid) matter.
In fact, tuples are actually less useful that they could be due to the lack of automatic conformance to some protocols when members conform to those, but that's a limitation of tuples that should be addressed independently. But that's not an argument against tuples per se, it's just an existing limitation.
What do you mean exactly? It's not possible to have "sealed" protocols in Swift (like sealed trait in Scala or sealed class in Kotlin), so a protocol cannot be closed over a predeterminate number of cases (that is, conforming concrete types), like an enum does, and like an union type would do, so the use case is different.
About the potential utility of union types, I wrote this post a few years ago with some examples, in the context of discussing the possibility of adding the Either type to the standard library.
I like this example. Do you mean that closures would not have to be escaping with union types nullability implementation?
For value types optionals are normally expressed as a tag 0-1 byte plus the payload – oversimplifying and leaving tagged pointers aside – so it's easy to see how nested pointers could be encoded: tag + tag + tag + T for some T??? type. Any idea how union types are represented internally?
What do you mean?
In this example?
if dict.hasKey("hello") {
if let value = dict["hello"] {
How come? dict can not be changed (e.g. in another thread).
It's not super efficient, and the key is getting looked up twice, I agree.
Fair point! However I find the dictionary distinction a much more useful one, that's worth keeping.
By "pointlessly" I mean that the natural infinite-nesting potential of Optionals that you get "for free" is being given up in exchange for no other perk, as far as I can tell.
Triple optionals are admittedly much less useful than doubly nested ones, but I do recall one instance where they were a natural/obvious solution to a problem I had, though I can't remember the details. Its ability to compose with itself, means you'll never be in a situation where you need to say, lazy-load a value where you need one more layer of optionality than the value. I frequently run into this in Ruby, which has this common memoization pattern idom:
def foo
@foo ||= compute_something_expensive
end
When some other code looks at @foo, it can't tell if it's nil, you can't distinguish "the foo wasn't loaded yet" from "the foo was loaded, but actually nil. You need to manually maintain some state in a boolean and keep it in sync, which is what optionals were doing all along.
Fair, I'll grant that I'm not a fan of needing special-cased features, though I think the end result is better than you could achieve with union types alone.
Good question! This is all my opinion, but I see 3 issues/short-comings of type unions, all of which are better solved with protocols.
In a statically-typed language, when you have a value like value: A | B, you can't call methods of A (because value might be a B), and you can't call methods of B (because value might be an A. The only methods you can call are those in the intersection of A and B, that is, methods that exist on both A and B (and have same arity, throwingness, asyncness, compatible parameter types, compatible return type, etc.):
A or B. This gets knarly, they take over your whole code base, and become a burden to write and maintain. If | C gets added to a return type of a function, now you need to update callers to account for that, just like adding a new case to an enum.Type unions don't express why the things are being unioned together. Really, why might something return a String | Int? What do those things have in common? Sure that's a contrived example, but it happens more generally, where completely unrelated types get unioned together, which is like a slightly more strongly-typed way to write -> Any, but that leads to similar runtime type-checking soup. You might say "oh, well they're related because they both have var description: String." Great, so what you're really after is CustomStringConvertible, not String | Int.
Protocols express requirements of conforming types, and for callers, those requirements are guarantees of the availability of some API, that can be called without casting or runtime type checking.
I'm wary to make an argument like "it can be misused so nobody can have it," but really, after reading a fair bit of TS code, I'm constantly seeing people run into a type error, and slap | SomethingElse on the return type as a way to make it go away, almost like how the Xcode fixit for an Optional type error is to force unwrap it with !. IMO, type unions are the ! of typing, they look simple and appealing, solve a very short-term problem, but sidestep the data-modelling step and just make a mess.
Type unions are sealed for extension. This might be a perk in some cases, but in general, I find it to be more of a hindrance, especially for testing. Protocols let you abstract over concrete types, while still letting you use stubs/mocks in testing. Unless you do A | B | TestDouble (which is its own smell), APIs that use type unions can't be test as easily.
// But I wanna draw a circle! 😭
func draw(shape: Square | Triangle)
protocol Shape {
func draw(into rect: NSRect)
}
// --------------------------------
extension Square: Shape { ... }
extension Triangle: Shape { ... }
extension Circle: Shape { ... }
func draw(shape: any Shape) // Nice.
/// A kind of shape that can be used with something that draws shapes,
/// to verify that it calls `draw`. Contrived/toy example.
struct SpyShape: Shape {
func draw(into rect: NSRect) {
expectation("shape was drawn").fulfill()
}
}
My general takeaway here is that type unions look really attractive because of how easy they are to write (A | B is so sleek, after all!), but that the discourse almost always ignores the mess of code you need to consume type unions.
Not quite. A type union would be more like a @frozen enum than an enum. That's the rub: when you have a public API that returns a type union, you can't add new stuff without breaking all the callers. There's times that's a perk (e.g. we don't want anyone adding new cases to Result), but the rest of the time it's a restriction on new API additions to the library.
That would be my objection to the enum FieldKind example in your linked post. You don't have a case dateField(DateField), and now you can't add it (assuming your enum was public API of a library) without breaking callers. A protocol FieldKind would have been better.
This is an interesting read, I think I'll need more time to mull it over!
One thing that sticks out is that the use of union types in function parameters is very much like the flag argument anti-pattern. Your function implementation ends up being one giant switch, instead of multiple tidy functions.
If that were the case, then we can do the opposite and shrink the surface of every library down to a single function! All you need is this:
func fn(args: Fn1Args(...) | Fn2Args(...) | ...) -> (Fn1Result | Fn2Result | ...)
Switching to a flag argument doesn't decrease surface, it just obscures it. A new overload does increase surface, but no differently than adding a new member to a type union of an existing function's parameter.
Thanks for the link. The examples you are presenting there could be solved via an unnamed enum (if we had it):
func handle(_ event: enum { case action(Action), change(Change)}) { ... }
func compute(_ strategy: enum { case statically, dynamically }) -> Int { ... }
except for those which don't use names but tuple style numbers .0, .1
func handle(_ event: enum { case 0(Action), 1(Change)}) { ... } // 🤔
@frozen is really about public interfaces, but internally within a module, enum is perfectly fine, and yes, it breaks the clients when you add a new case, which is exactly what I, and most people, want most of the time. Also, still, even a non-frozen enum in a public interface helps the compiler, because if a new case is added, the @unknown declaration emits a warning. Thus, enums and type unions are nothing like general protocol subtyping.
Yep, and that's what I want from a union type.
No it wouldn't. It might be the case that our approaches to programming in general are very different, but it seems that the things you are considering bad or gnarly are exactly what I want 
I (along with many others) want closed types that I can switch upon, with the compiler guaranteeing that the switch is exhaustive.
I've been programming in Swift from the very beginning, and this thing that you consider a "perk" in some cases is one of the most important, foundational features of Swift, that I used for years with great gain.
Again, it could simply be down to a matter of code style and approach. For example, consider this sentence:
I completely disagree with this. I think "multiple tidy functions" is an anti pattern that makes a code base 10x more complex, while modeling actions with value types, as I observed over the years, makes the code more maintainable in the long run.
It's different, because the type union is a first-class value that, as any other value, can be transformed, have properties and methods, et cetera. It unlocks a very different type of programming – that I would suggest to explore – that uses modeling as the essential way to tackle complexity.
But in that case I would use an actual named enum, there are only a few cases where an anonymous type union could be considered when dealing with function inputs.
That might be it!
This is similar to the checked vs. unchecked exceptions debate. With checked exceptions, enums, type-unions, etc., callers gain switch exhaustiveness, but that comes at the cost of library authors losing the ability to make additive changes.
There are times when I value exhaustiveness (e.g. NSComparisonResult), but I much much much prefer library evolution flexibility.
Why? Just because of nesting?
It's even still fully compatible with a union-based approach, it just does not happen "accidentally". Considering the confusion and inconvenience caused by nested optionals, I consider that a really big plus.
That's a fair point. For library evolution @frozen enums (thus, anonymous union types) could be problematic, but I think there's still value in leveraging the options we have, like @frozen, @unknown et cetera, to handle the cases where we don't want a fully open interface. Still, not all problems are related to library evolution so I think anonymous sum types are still a good idea.
Yep. It's a nice little emergent feature of the enum-based design.
IMO, the confusion/inconvenience stems from the concept of missing being different from present-but-nil, which will exist regardless of how you end up representing it. It's not specific to nested optionals, I think a JS-like distinction of undefined-vs-null is equally (if not more) confusing and lacks the elegant self-consistency of Optionals and how they can nest.
Why wouldn't the feature at hand be implemented as non-nominal enums?
If it's not named, how do you put one instance inside another, without being able to refer to the type by name?
Like with nested tuples. They can have implicit numerical labels, or given labels. Likewise, an anonymous enum, could e.g be spelled like this:
func doSomething(with argument: (a: String | b: Int)) -> Result {
switch argument {
case .a(let value):
// value is a String
case .b(let value):
// value is an Int
}
}
func doSomething(with argument: (String | Int)) -> Result {
switch argument {
case .0(let value):
// value is a String
case .1(let value):
// value is an Int
}
}
¯\_(ツ)_/¯
Other spellings are probably possible.
I wonder how does Rust and other languages handle this, are optional closures always escaping in there as well?
There's been multiple discussions about optional non-escaping closures before, and it seems highly feasible to include escaping analysis to optionals (and possibly other types) as well.