[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi]

Leonardo, how is defaulting to final/sealed helping you write better libraries than having a final keyword for what you need to close instead?

Sent from my iPhone

On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:

>> The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:
>> 
>>        https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>> 
>>        * What is your evaluation of the proposal?
> 
> +1. Being able to control how a class from my libraries are going to
> be used by third-parties could enable a better designed API with more
> control of how it is intended to be used. I'm just not fond of using
> the proposed keywords ('subclassable' and 'overridable') as they feel
> more like protocol or attribute names; I'd be more inclined to use the
> alternative 'public open' instead, or 'public(open)' as a second
> option.
> 
>>        * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> I'd say it is significant to every language.
> 
>>        * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>>        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> C# uses the keyword 'virtual' to explicitly mark methods that can be
> overriden (not considered in the alternatives but I'm not a big fan of
> it).
> 
>>        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> I've took (a small) part on the thread discussing this proposal but
> followed it closely
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution