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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
