[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

[Nevin Brackett-Rozinsky]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170228/bc475472/attachment.html>