So, just to clarify again - adding a new keyword to the language has an extremely high bar because of the costs involved. We’ve been working hard to get rid of keywords rather than the other way around. So unless we come up with something extraordinary, we will not be adding a new keyword for this outside of a modification of let like the proprosed let?.
Some more comments:
The modification (? in let?) needs to happen in the let binding itself. This means in the let keyword, or possibly in the assignment (?=). But all other places are out as of now, because they would either interfere with existing features or complicate exploring other features in the future (like optional chaining).
The current design with explicit unwrapping means that you could, in theory in the future, get to decide yourself which constructor you want to unwrap. If you have a variant with more than 1 possible “continuation” constructor.
This can be a problem of course, but the hidden part never has any logic, it just forwards None or Error(e). So our belief is that it’ll be fast to pick up and understand. But it’s less obvious than stating the full code of course, which is a trade off for sure.
This is a design goal of this feature though. In order to encourage composability and interop between libs and so on, some form of common type is needed. Result and options are perfect for that, and they’re first class in the language for this very reason.
But, the design of this feature leaves room for exploring using this with other variants as well in the future, especially thanks to being explicit about which case you’re unwrapping.
Nothing is wrong with this code, you can work like that today if you want to. But the pattern we’re talking about here is for propagating errors-as-values (or None), which is another thing than using exceptions.
Two things are important to highlight here, seeing what questions are asked in general in this thread:
- We’re not hiding any happy path here.
NoneorError(e)is propagated, so you’ll be forced to explicitly handle them somewhere. This is important and part of the design. - If we for some reason were to find that this feature is a net negative, rolling it back it would be as simple as just transforming to switches. So the cost of experimenting with this is low, and essentially risk free.
Again, thanks for all your thoughts and feedback! We read and consider all of it, and it’s very valuable.
Ultimately not everyone will be 100% happy with whatever we chose to move forward with. Such is the life of a programming language 
But hearing your thoughts, feedback and ideas is extremely valuable and important to us.
Keep it coming. Right now we’re aiming to move forward with this for v12.1 the soonest.