Regards
(From mobile)
> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution
> <swift-evolution@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@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@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@swift.org> wrote:
>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell
>>>>> <michael.petern...@gmx.at> wrote:
>>>>>
>>>>>
>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution
>>>>>> <swift-evolution@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@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
