Hi Matthew,

> On 17 Feb 2017, at 10:28, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> As I have said elsewhere, I think the mental anguish mostly derives from the 
> fact that scoped private is not the right “default” in a language that uses 
> extensions pervasively.  Chris’s suggestion of having private mean “same file 
> *and* same type” would be a good default.  But if we’re not willing to *also* 
> have fileprivate then the Swift 2 definition of private is the best 
> “default’.  
> 
> I still think scoped access control is valuable but taking `private` as the 
> keyword for this was a mistake.  I’d like to see us take another stab at 
> identifying a suitable name for it.  That said, I get the feeling that not 
> too many others have appetite for this so it may be a lost cause…

I agree - I’d love to see the current list of controls refined. 

Personally, (and I understand that everyone has different needs) I see little 
point to `private` and `fileprivate` as they are implemented in Swift 3. If I 
have access to edit the source file of a class, what purpose does `private` in 
Swift 3 even serve? Documentation? Surely there are better ways to come at that 
issue? 

Similarly, `fileprivate` means I need to put my extensions in the same file as 
the original class, leading to unnecessarily large source files. 


My preference would be replacing `private` and `fileprivate` with “same file 
and same type” as you mentioned. Ultimately, most of my current use cases that 
would take advantage of this could be handled by splitting my code into 
separate frameworks and using `internal`.

Cheers,


Tony



----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to