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

[Anton Zhilin]

This proposal should be reviewed as a part of “typed throws” proposal, with
the original PR <https://github.com/apple/swift-evolution/pull/68> prepared
by David Owens.

Typed throws won’t change anything about how many types can be thrown. Only
one type/protocol will be specified in the function type. You will still be
able to specify throws Error by default, but in the cases, where API
authors put some effort in their error handling, these APIs will be
self-documented and undoubtably easier to work with. In many cases, one can
at least specify some existential error type, which will be
domain-specific, and still better than what we have now.

I feel like Swift, together with Rust, can change current overall mess in
error handling across many programming languages by providing not only
syntax, but also semantics and guidelines. Swift errors, unlike exceptions,
require dealing with them immediately. If one cannot deal with the error,
but error details can be useful on hier levels of abstraction (for actually
solving the problem, not logging), he still should put some work into
wrapping the error, leaving only important details and preparing them for
most conventient access.

On syntax, I feel like this is the obvious one:

func convert(_: String) -> Int throws IntegerConversionError

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?
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161227/31ea8015/attachment.html>