[swift-evolution] [Proposal] Sealed classes by default

Jean-Daniel Dupas mailing at xenonium.com
Wed Jun 29 15:16:54 CDT 2016


> Le 29 juin 2016 à 21:41, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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).

I also though about public(final), but it may be confused with "public final" which can be used to defined a class final even in the module scope.

> 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
> <swift-evolution at swift.org> 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 <swift-evolution at swift.org>:
>>> 
>>> 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 <swift-evolution at swift.org> wrote:
>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell <michael.peternell at gmx.at> wrote:
>>>> 
>>>> 
>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution <swift-evolution at 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 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
>> 
>> _______________________________________________
>> 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



More information about the swift-evolution mailing list