[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly
felipe at cypriano.me
Mon Jul 18 20:30:51 CDT 2016
The revised proposal is much nicer. I'm still onboard on having classes
sealed by default, but not as much on class members. Initially I felt
that members should follow the same semantics as the class to avoid
confusion, but I've read all the other emails I think I changed my mind.
As demonstrated by Károly, it is pretty simple to create a internally
opened method by having a public final method that calls the internal
one. To me having open only applied to class provides a nice balance to
On Mon, Jul 18, 2016, at 03:48, L. Mihalkovic via swift-evolution wrote:
> (From mobile)
> On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon
> <brent at architechies.com>
>>> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution <swift-
>>> evolution at swift.org> wrote:
>>>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution <swift-
>>>> evolution at swift.org> wrote:
>>>> Is there a summary somewhere of the motivation for allowing methods
>>>> to be declared non-overridable within open classes?
>>> Because 1) someone woke up one morning and thought it would be great
>>> 2) it goes into the direction of making swift a language for non
>>> programmers 3) the core team wants it
>> Laurent: This is not a fair characterization of the actual position
>> of the proposal's supporters. If you can't be civil about this topic,
>> perhaps you shouldn't be discussing it at all.
> 3) the core team was very clear that it is the
> direction they want for the language.
I have edit the original message to focus only on point number 3.
Garth asked specifically about class members, not class themselves.
The core team "believes with conviction" that classes should not be
open by default but they asked more discussion on the "overridability"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution