I suggest we all take a step back and return to the original proposal -
Either is a nice type and I'd like to have it at my disposal, but is it in conflict with the
Result? No, it is another type. It is a more generalized version of
Result. It does not conflict with
Result. Focus on the semantics. Semantics of the
Result type is well-known. Either I get a value
T or an error
E: Error. This is different from
Either where I expect either a value
T or another value
U. Since semantics is so clear in these cases, the only way it makes sense for
Result to be implemented is to have error constrained
Error: Swift.Error - otherwise we are talking about
Either type and that's not a topic of this proposal.
Result a backdoor to introducing typed throws? It is such a harsh way to put it, but even if it is, is that really a bad thing? Is allowing typed throws necessarily a bad thing? There are so many use cases where typed errors are useful so why not allow them. They don't have to be forced upon users, but they could be allowed. The way I see this, is that there is a pressing need for
Result type. It's solves so many problems that the Swift community is experiencing today. It is potentially a building block of a better error handling system, that may or may not come. It allows us to make our code more expressive.
Could it become obsolete when we get better concurrency support? It is likely that its usage will drop significantly. But will it conflict will anything, will it limit us to do better? No.
What I loved about early days of Swift is that there was no huge fear of change. I understand that there is so much more responsibility these days, but openness to new things is what got Swift to this point of being a great language to work with. I would hate to see it stagnate.