[swift-evolution] [Proposal] Revising access modifiers on extensions
Adrian Zubarev
adrian.zubarev at devandartist.com
Tue Jun 28 14:40:11 CDT 2016
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 (cheyo at masters3d.com) 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/74e54ae7/attachment.html>
More information about the swift-evolution
mailing list