Rien, your example shows two things (well, three, but one relates to variadic arguments not access levels).
First, it shows the importance of being able to prevent external overrides of individual methods. I did not directly address that in my pitch, however it could easily use the same syntax as closed classes, namely ‘final(public)’. I am not tied to that particular spelling, it just seemed logical—better ideas are welcome. Second, your example shows that even with today’s “soft default” of closedness, developers still sometimes erroneously allow subclassing or overriding. To put that another way, when a library author thinks something should be ‘open’ in Swift 3, they mark it as such. The decision to make a class or method closed is an intentional one, even today. Having it be a “soft default” does not and cannot prevent the type of error it is alleged to. Also, unless there are subclasses in your library which override that variadic convenience method, it should probably be marked ‘final’ and just call through to the overrideable workhorse array-based version. No ‘closed’ required here. This provides further evidence that most of the time, methods should either be overrideable or final, as ‘closed’ is a rare niche case. Nevin
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
