> On Dec 27, 2016, at 06:38, Anton Zhilin via swift-evolution
> <[email protected]> wrote:
> On syntax, I feel like this is the obvious one:
>
> func convert(_: String) -> Int throws IntegerConversionError
I agree this is the best syntax, though I might add a comma in there for even
more readability:
func convert(_:String) -> Int, throws IntegerConversionError {
...
}
I wonder if this might be problematic in the presence of trailing where clauses
though, as in this contrived example:
func doSomething<S:Sequence>(seq:S) -> Int where S.Iterator == T, S.Iterator:
Hashable, throws SomeKindOfError {
...
}
It seems like it should be alright, but perhaps I’m missing something.
-Matt
> Basically, we say that the function can either return an Int, or throw an
> IntegerConversionError. (Side note: yes, not NumericConversionError, if we
> want the API to both provide most detailed information when we need it, and
> express the range of possible errors for a particular function through the
> type system. However, one can also create hierarchies of error protocols to
> aid in abstraction—both abstraction and preciseness are important.)
>
> But can we make a step even further? One can say that the function returns
> “either Int or an error”. Rust users blame Swift for creating syntax sugar
> for everything—maybe we can live without it this time? Look at it this way:
> we already have a deep support for Optional<T> in the language. It’s so
> seamless, many people don’t even realize they work with Optional<T>. Can we
> make working with a standard enum Result<T, E> this simple?
>
> We can even leave current syntax in place, just T throws E will be a sugar
> for Result<T, E>. Methods of error handling described in this manifesto
> <https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst> will be
> represented, respectively, by Optional, Result, and fatalError, with all of
> them defined in the standard library—isn’t that reasonable?
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
