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

[Leonardo Pessoa]

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
<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