I like `closed` better because it would pair up nicely with `opened` `opened` would be a good keyword imo (applying the ing/ed rule).
In the future if we ever support open enums, we could use the same keyword. :) > On Jun 29, 2016, at 11:16 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Jun 29, 2016, at 11:11 AM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Do we really need a new keyword? Since we already have syntax like >> `internal(set)` couldn't we do `internal(unsealed)`, etc. > > The spelling is definitely up for debate. I remember that Chris in > particular wasn't happy with "sealed". > > (Of course the entire proposal is still up for debate; I'm just saying that > so far we've been talking about the proposal at a high level with very little > attention to specifics.) > > John. > > >> >> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > On Jun 29, 2016, at 12:15 PM, Michael Peternell <michael.petern...@gmx.at >> > <mailto:michael.petern...@gmx.at>> wrote: >> > >> > >> >> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> >> >> +1 for the concept of a "sealed” class. >> >> -1 for making it default. >> > >> > Aren't sealed classes already implemented? I think the keyword is `final`.. >> > So there is nothing left to do :) >> >> No, `final` doesn’t allow for any subclassing, but `sealed` allows for >> subclassing within your module (where you can presumably write more >> efficient code based on knowledge of each subclass). >> >> - Dave Sweeris >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
