I think the alternative spellings could use an expansion on the idea of making Result closely resemble Optional.
enum Result<Wrapped, E> {
case some(Wrapped)
case error(E)
}
Where E could be any spelling.
The only reason I bring this up is because .some would be important if we generalize the ? and if let unwrapping to also work with Result types.
Just a quick thought: Would it make sense to add the following conditional conformance?
extension Result : Swift.Error where Error : Swift.Error {}
So a result can be an error with either an error or a default value wrapped in the success case?!
On the other hand I‘m not entirely sure if the where clause is necessary at all.
I don't really see how that would be useful. It wouldn't really make sense to throw a Result.success(...).
The result already contains this, which should be fine for going back from a result to normal Swift error handling:
extension Result where Error: Swift.Error {
/// Unwraps the `Result` into a throwing expression.
///
/// - Returns: The success value, if the instance is a success.
/// - Throws: The error value, if the instance is a failure.
public func unwrapped() throws -> Value
}
This seems exactly opposite to me. Result is the type that you can implicitly assign to a variable name and ignore, or throw in a queue for reactive use cases. Result is the one where you might flatmap in more logic (which - doesn’t that break with typed errors in results?)
Errors are what require you to always acknowledge if not deal with the error at a syntactic level. You can delegate up, but you aren’t really meant to be deferring an error - you instead are putting a part of the system into an error state. Deferring an error would be... wrapping it into a result
This pitch is now in review, under the SE-0235 name.