I actually thought about something like 'public(final)' as it may make it clearer the intention to the class (and no new keywords were introduced).
Also I think we should draw a guideline for such naming because there are always so many suggestions. Having a guideline would reduce our efforts in choosing names. L On 29 June 2016 at 15:16, Michael Peternell via swift-evolution <[email protected]> wrote: > Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really > make sense. `internal` declarations are always sealed. > > -Michael > >> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution >> <[email protected]>: >> >> Do we really need a new keyword? Since we already have syntax like >> `internal(set)` couldn't we do `internal(unsealed)`, etc. >> >> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution >> <[email protected]> wrote: >> > On Jun 29, 2016, at 12:15 PM, Michael Peternell <[email protected]> >> > wrote: >> > >> > >> >> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >> >> <[email protected]>: >> >> >> >> +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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
