Rien, your example shows two things (well, three, but one relates to variadic arguments not access levels).<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Nevin</div>