[swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

[Haravikk]

I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to have typed errors that the compiler can use to check for an exhaustive list, as it would be easy for a forced conversion to result in unexpected runtime errors later if you ever need to add a new error type to your .applyAction() method, since doing so wouldn’t result in any warnings/errors at compile time.

I agree about catch _ and default; either default should be allowed for do/catch, or be removed from switches, to promote consistency, but that’s a separate issue I think.

> On 20 Mar 2016, at 20:26, Tyler Fleming Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I recall that there was quite a bit of discussion a while back about adding typed error declarations for methods that throw for the purpose of exhaustive pattern matching on errors.
> 
> There were interesting arguments on either side, and I think that the result was to maintain the status quo. There’s still the issue of having to add the extra catch statement to every do block for exhaustive matches.
> 
> Would it be wise to allow force conversion for the cases in which the developer believes the match is exhaustive? ie
> 
> do {
>     let action = chooseAction(game)
>     game = try game.applyAction(action)
> } catch let e as ActionError {
>     game.failedAction = e
> } catch _ {
>     fatalError(“This is an unfortunate bit of noise :/")
> }
> 
> becomes
> 
> do {
>     let action = chooseAction(game)
>     game = try game.applyAction(action)
> } catch let e as! ActionError {
>     game.failedAction = e
> }
> 
> 
> Also as a brief aside, it’s not super intuitive to me that the syntax for the catch pattern matching wildcard is 
> 
> catch _
> 
> whereas it is
> 
> default
>  
> for switches. I think I saw Chris mention somewhere that default was chosen because of it’s wide familiarity. Does anyone recall the reason?
> 
> Thanks,
> 
> Tyler
> _______________________________________________
> 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/20160321/4cb7b8c1/attachment.html>