[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