> On 5 Apr 2017, at 03:45, Brent Royal-Gordon <[email protected]> wrote:
> 
>>> On Apr 4, 2017, at 12:30 PM, David Hart via swift-evolution 
>>> <[email protected]> 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
> 
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to