Sent from my iPhone > On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner <clatt...@nondot.org> wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> A question about the new #unknown behavior. Is it intended to be used for >>> error handling too ? >>> Will it be possible to use in catch clause ? >> >> If we go with the #unknown approach, then yes of course it will work in >> catch clauses. They are patterns, so it naturally falls out. > > It will not work in catch clauses because you need to have a static type > that's an enum. Catch clauses always (today…) have a static type of 'Error'. > > >> >> If we go with the “unknown default:” / “unknown case:" approach, then no, >> this has nothing to do with error handling. >> >> IMO, this pivots on the desired semantics for “unknown cases in enums”: if >> you intentionally try to match on this, do we get a warning or error if you >> don’t handle all the cases? If we can get to consensus on that point, then >> the design is pretty obvious IMO. > > That's fair. I'm strongly in favor of a warning, though, because again, > people don't edit their dependencies.
A warning is better than nothing :), but for third party libraries you include in the app you are responsible for not updating to a library that would break your build and between compiler and automation catch this error before merging a PR and putting it in production. It is also your responsibility to reasonable choose a library that is properly maintained and vetted. > > Jordan > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
