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

Taras Zakharko taras.zakharko at uzh.ch
Mon Jul 18 11:24:39 CDT 2016


> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> I see no drawback to this pattern; it is quite clear and simple. Therefore, in the interest of keeping the language free of needless complexity, I suggest we change the proposal to remove the implicit "sealed" level of public member overridability, and support only "open" or "final" class members.


At the same time, your solution results in a lot of unnecessary boilerplate. Sure, it might be rare with methods, but don’t forget about properties! It makes perfect sense to have properties that should be only overridable internally while being accessible publicly. Imagine adding that boilerplate to every such property.. 

Basically, if we do it your way, then it won’t be long that someone submits a proposal for a keyword for synthesising the boilerplate, which more or less brings us back to square one.  

T.


 


More information about the swift-evolution mailing list