[swift-evolution] Warning when omitting default case for imported enums

[Robert Widmann]

I lean +1, but this answer on its own seems incomplete.  Exhaustiveness is an important property, and it’s not clear what happens here now when you fall through a “complete” case tree without matching a pattern, and in that sense this plan solves a problem.  But it also would hinder a “future-you” from going back and dealing with the ramifications of swapping a dependency for a newer version, in that with a default now covering the rest of the cases the compiler is unable to tell you which cases you are actually missing post-upgrade.

Library Evolution <https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst> includes what I think is the more complete response here: An @closed attribute for enums where a switch is guaranteed to be exhaustive.  (Though, after the open discussion, I wonder if that keyword can’t be reused in some way to provide the inverse restriction instead).

> On Feb 7, 2017, at 10:12 AM, Tanner Nelson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift Evolution,
> 
> I'd like to propose that a warning be emitted when default cases are omitted for enums from other modules. 
> 
> What this would look like:
> 
> OtherModule:
> ```
> public enum SomeEnum {
>     case one
>     case two
> }
> 
> public let global: SomeEnum = .one
> ```
> 
> executable:
> ```
> import OtherModule
> 
> switch OtherModule.global {
>     case .one: break
>     case .two: break
>     ^~~~~ ⚠︎ Warning: Default case recommended for imported enums. Fix-it: Add `default: break`
> }
> ```
> 
> Why:
> 
> Allowing the omission of a default case in an exhaustive switch makes the addition of a new case to the enum a breaking change. 
> In other words, if you're exhaustively switching on an enum from an imported library, the imported library can break your code by adding a new case to that enum (which the library authors may erroneously view as an additive/minor-bump change).
> 
> Background:
> 
> As a maintainer of a Swift framework, public enums have been a pain point in maintaining semver. They've made it difficult to implement additive features and have necessitated the avoidance of enums in our future public API plans.
> 
> Related Twitter thread: https://twitter.com/tanner0101/status/796860273760104454 <https://twitter.com/tanner0101/status/796860273760104454>
> 
> Looking forward to hearing your thoughts.
> 
> Best,
> Tanner
> 
> Tanner Nelson
> Vapor 
> +1 (435) 773-2831
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20170207/9d087a34/attachment.html>