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

[L. Mihalkovic]

Regards
(From mobile)

> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> How about `public(extensible)` ?
> 
> On 29.06.2016 21:32, John McCall via swift-evolution wrote:
>>> On Jun 29, 2016, at 11:16 AM, 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.
>> 
>> Right.
>> 
>> If "sealed" is the default behavior for public classes and methods — and I don't think the modifier is worth adding unless it's the default

What a jump... I am very curious about this rational that seems so obvious to you?

>> — then we need a way of "unsealing" classes and methods that's fairly pithy.  I don't think a parenthesized spelling is good enough for that.  And we should try to make the positive form ("can be overridden") shorter than the negative ("cannot be overridden"), because the latter will not usually be written.
>> 
>> To me, the ideal spelling would be usable in place of "public".  If it does have to be stacked with "public", then I think it ought to be pretty short.
>> 
>> "communal"? :)
>> 
>> "open" doesn't carry quite the right meaning, and it would need to be paired with "public", I think.
>> 
>> John.
>> 
>> 
>>> 
>>> -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
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution