[swift-evolution] [Proposal] Nested extensions
2th at gmx.de
Sat Apr 15 02:41:40 CDT 2017
Thank you for you comment, Xiaodi.
I understand the disappointment, but imho this proposal is quite different from the ideas that have been rejected, and I hope to be able to convey that standpoint:
> One solution to the problem is to remove the use of access modifiers as a shorthand in front of extensions. It was proposed, reviewed, and rejected:
> https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md>The rational for the rejection was that this proposal would eliminate the useful ability to apply access control to a batch of methods and properties.
This can't be a motivation to discard nested extensions — it does not try to remove batching of access control, but rather extend that ability to be used for stored properties.
> I tried to follow up with a much milder proposal to change the rules surrounding access modifiers. It was discussed here:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024588.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024588.html>
> The PR was here, but rejected for review by the core team:
> https://github.com/apple/swift-evolution/pull/438/files <https://github.com/apple/swift-evolution/pull/438/files>
I don't think this has much similarity either:
I'm not trying to change extensions itself, but rather leverage their existing capabilities in a bigger context.
To make it clear:
A private extension that is nested would would be completely inaccessible (and therefor useless) unless you have at least one member in it whose access level is set to internal (or more accessible).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution