How do private or fileprivate help extensions in general? Is really laziness a 
strong argument over consistency and clarity?

As for your example I’d have a pretty good solution (I can’t say this will be 
accepted, but the idea is great, at least I think that way. I’d propose for 
that feature after Swift 3 drops):

// Use correct consistent access control
fileprivate extension Int {
     
    // every member of a nameless group would be `fileprivate`
    fileprivate group {
     
       func double() -> Int {
           return self*2
       }
        
       func member1() {}
       func member2() {}
       func member3() {}
       func member4() {}
    }
}
A group could do way more than just in this example: 
https://gist.github.com/DevAndArtist/c74f706febf93452999881335f6ca1f9

We’d move the behavior out into its own more powerful feature.



-- 
Adrian Zubarev
Sent with Airmail

Am 28. Juni 2016 um 03:14:08, Jose Cheyo Jimenez ([email protected]) schrieb:

I would be against removing access modifiers on extensions. I actually don't 
see anything wrong with the way extensions work with modifiers right now.  
Consistency for consistency's sake is never a good measurement if it is not 
addressing a pain point. 

When ever I extend a swift standard type, I always make it "fileprivate" 
because I don't want to pollute autocomplete for that type. 

fileprivate extension Int {
   func double() -> Int {
       return self*2
   }
}

My understanding is that private / fileprivate was renamed/introduced to help 
with extensions. I don't think extensions need anymore complexities. I would 
hardly ever use private in swift 3 for example (when it gets implemented.)
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to