[swift-evolution] [Proposal] Typed throws
Martin Waitz
tali at admingilde.org
Sat Feb 18 15:16:31 CST 2017
> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution <swift-evolution at swift.org>:
>
> Thank you for taking the time to put this proposal together Anton! I really want to see typed throws make it into Swift 4. This will be a very nice feature to have.
>
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by making every function have an error type which is by default `Never` for non-throwing functions and `Error` for throwing functions that do not specify an error type.
>
> I want to urge you to consider updating the proposal to take this direction now rather than later. This is a breaking change which means the longer we wait the harder it is to justify. In fact, I think incorporating the breaking change could increase the chances of it being accepted for Swift 4. Without that it is a purely additive change and those are not being given priority in the Swift 4 release.
Seconded.
With typed throwing function parameters, it makes a lot of sense to be able to specify the rethrown type, based on the function given as parameter.
Now some bike-shedding:
I’m not really happy with the `throws(Type)` syntax, as it is too close to function parameters.
Why exactly is `throws Type` ambiguous?
The proposal mentions `Type -> Result` as potential thrown type, but functions cannot conform to `Error`.
Maybe we can instruct the parser to just allow simple type names between `throws` and the arrow `->`.
If that is not possible, we should at least try to find some visual hints to separate Error type from function parameters.
E.g. we could use brackets (think of: we are specialising the `throws`):
func foo() throws<MyError> { … }
— Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170218/a9cf628d/attachment.html>
More information about the swift-evolution
mailing list