> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution > <swift-evolution@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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
