[wwalexander]

Combining them in general makes sense to me, at least to the extent of having an Optional<T> be an alias of Result<T, ()>.

There are some obvious cases where a none optional is separate from failure, like a hash map lookup or an element from an iterator. But I often also see optionals used to signal e.g. an unparseable string, where it would seem equally reasonable to return a Result or throw an error.

I’ve been writing a lot of Swift lately, and because it uses `throws` rather than a Result type, it’s made the often arbitrary choice of returning an optional value or raising an error more noticeable to me. Especially when using `async`, as pretty much everything declared `async` also throws, so if an Optional is actually what you want to return, you get some fairly gross boilerplate at the site of use:

    guard let value = try await getValue() else { … }

This has turned into a bit of a ramble but my main point is that implementing Optional as a Result with void error type makes a lot of sense in my head.

[amedvednikov]

Yeah that was my idea initially when I designed the language.

I don't think any other language has them merged.

There were issues later with the 3 states (Ok, Error, none) instead of a simple binary state.

Since the `or {}` block handles the "not Ok", developers had to check whether it was an Error or a `none`, it's not pretty.