[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Drew Crawford drew at sealedabstract.com
Tue Mar 21 21:31:42 CDT 2017

On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:

You're not hearing the argument. No one "accidentally" included this design as part of SE-0025; it's sentence number one. 
To quote this in context:

Scoped access level allows hiding implementation details of a class or a class extension at the class/extension level, instead of a file. It is a concise expression of the intent that a particular part of a class or extension definition is there only to implement a public API for other classes or extensions and must not be used directly anywhere outside of the scope of the class or the extension.

I can see how an adversarial reading of the first sentence would argue that implementation details are not actually hidden by your example (which is, for the record, technically correct, the best kind of correct :-).  However, the second sentence clarifies which kind of implementation details we mean to hide – the accidental use of members outside the scope.

Your example does not involve hiding in that sense, so while it is interesting, and a bug, and should be fixed, etc., it does not thwart the practicable goal of the proposal.

And no one just "forgot" to make the code above work; it simply can't be accommodated by the current mangling scheme. 
The Swift mangling scheme changes with some frequency, I know of around 3 revs offhand and I do not work in that area often.  So holding this up as an immovable object is odd.

Things would be different if we declared a stable ABI, but we did not, etc.

And--what's more--_no one seems to be bothered by it_.
I volunteer to be bothered by it.  Where’s my cookie?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/95621c38/attachment.html>

More information about the swift-evolution mailing list