> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon <[email protected]> > wrote: > >> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu <[email protected]> wrote: >> >> So, perhaps I'm being simplistic here, but-- >> >> At the end of the day, aren't we simply trying to enable a resiliency >> feature? Could it not be said that an enum where future added cases aren't >> source-breaking is a more resilient enum? >> >> Since there is consensus that the status quo is desirable for a lot of use >> cases, couldn't we keep spelling it "public enum" and just spell this >> proposed more resilient enum "@resilient public enum"? > > Our philosophy in general, however, is to default to the behavior which > preserves the most flexibility for the library designer. Both open and > non-open classes are common, but we chose to give non-open classes the > `public` keyword because that's the flexibility-preserving option. Resilient > enums are definitely the more flexible option, so by that rule, they should > have plain `public`. > > I think that, if enums were a brand-new feature being introduced for the > first time in Swift 4, there would be no question that `public enum` ought to > give you a resilient enum. The only good reason not to do that is source > compatibility. So we need to decide: Which of these principles is more > important to us? > > 1. "Defaults for public symbols should preserve as much flexibility for > designers as possible." > > 2. "Swift 3 code should compile in Swift 4 without deprecation warnings, > unmodified and without a version compatibility flag, whenever possible.”
It’s also worth re-iterating the point I have made about inconsistent semantics for `public`, and that this problem as well as your first point also impacts protocols. That means we have two reasons to make a change and both impact protocols and enums. We also have a very reasonable way to introduce the changes necessary to solve these problems. I think the changes are worth making, and certainly worthy of at least bringing a proposal to review. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
