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

[Derrick Ho]

-1
I prefer to have enums enforce that all cases are met otherwise use a
default value.


If an API changes and adds new cases I want to know about it so that I can
do something about it! If we hide it then weird and mysterious bugs might
creep up
On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via swift-evolution <
swift-evolution at swift.org> wrote:

> That's awesome. It looks like `(planned) Open and closed enums` is
> exactly what I'm looking for.
>
> Would it help if I created a concrete proposal for that or is it something
> the Swift team already has brewing?
>
> Sent from my iPhone
>
> On Feb 7, 2017, at 22:01, Michael Ilseman <milseman at apple.com> wrote:
>
> BTW, this will likely be part of the eventual design of “open”/resilient
> enums ala
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums.
> There, the goal is to reduce both ABI and source breakage caused by this
> sort of thing. It seems like for your purposes, you’re less inclined to
> care about ABI breakage than source breakage, though that may change in the
> future.
>
>
>
> On Feb 7, 2017, at 7: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
>
> 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
>
>
> _______________________________________________
> 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/d9927f8b/attachment.html>