- What is your evaluation of the proposal?
+1
- Is the problem being addressed significant enough to warrant a change to Swift?
Very much! I'm using it in all my projects and very often I'm dealing with multiples implementations at the same time which is unfortunate. I would love to see universal solution provided by the standard library.
Does this proposal fit well with the feel and direction of Swift?
Generally very well. I'm very much in line with @beccadax thoughts here, but in a strong favour of typed errors.
Although in most cases they are not need, there are occasions when typed errors are very useful. I've stumbled upon such cases many times and I would rather not have Result in the standard library than have one with untyped errors. That being said, I'd also love to have Result that is simple to use with untyped errors, like Slava suggested by making Swift.Error conforming to itself. I think this would be a big win, not just for Result, but also for other types like Futures or Signals.
In addition to that, I'd also love to see Error generic parameter defaulted to Swift.Error. In other words, my ideal Result type would be defined like: Result<Value, Error: Swift.Error = Swift.Error>. I know this is not possible now because default generic parameters are not supported, but they are in the manifesto and have their usefulness so I hope to see them supported eventually and then the whole discussion about typed vs. non-typed error becomes pretty much pointless. Therefore, let's us not constrain ourselves to untyped errors.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study.