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 the language. --- On Mon, Jul 18, 2016, at 03:48, L. Mihalkovic via swift-evolution wrote: > Regards > (From mobile) > > On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon > <[email protected]> > wrote: > >>> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution <swift- >>> [email protected]> wrote: >>> >>>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution <swift- >>>> [email protected]> 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" of members.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
