[swift-evolution] Move placement of 'throws' statement

[Matt Whiteside]

> On Dec 27, 2016, at 06:38, Anton Zhilin via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/86e3e7b7/attachment.html>