[swift-evolution] Type-based ‘private’ access within a file

David Hart david at hartbit.com
Wed Apr 5 00:55:36 CDT 2017



> On 5 Apr 2017, at 03:45, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>>> On Apr 4, 2017, at 12:30 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> And it throws out a major use-case of scope-based access, which is to ensure that invariants are only touched in specific places.
>> 
>> Is still retains most use-cases that private procured. The only capability that is not expressible in this model is to hide private members in a declaration or extension from other declarations/extensions of the same type. But it still allows hiding the member from other types in the same file, which is the most important aspect of private IMHO.
> 
> Well, therein lies the rub—MHO is that it's more useful to be able to hide one part of a type from other parts; YHO is that it's more useful to be able to hide one type from other types. There is no obvious reason why MHO is better or worse than YHO; there's no knock-out argument or example that produces an "a-ha!" moment. It's just a zero-sum argument about convenience, mired so deeply in personal coding styles that I'm not convinced we can ever satisfy everyone.

Very good summary of our conflicting points. But I don't believe it's a zero-sum argument. Here's why:

• No other language I know of allows you to hide one part of a type from other parts. How can this feature be so important we have lived without it in mainstream languages up to now?

• Swift's reliance on extensions for logical grouping and conformance increases the need to share between between parts of a type.

> That's why I think at this point that we should just drop it. Access control is a tar pit; let's not drown in it.
> 
> 	Once I get all this agreed upon, I'll pick up a pen
> 	And introduce a motion never to discuss this again
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/a2602f8d/attachment.html>


More information about the swift-evolution mailing list