[swift-evolution] [Proposal] Nested extensions
Xiaodi Wu
xiaodi.wu at gmail.com
Sat Apr 15 09:54:51 CDT 2017
I think you misunderstand. The rules of access modifiers do not currently
work with nested extensions without modification. How do you intend to
modify the rules? Previous attempts to do so, which were in part to make
possible nested extensions, were rejected.
On Sat, Apr 15, 2017 at 02:41 Tino Heth <2th at gmx.de> wrote:
> 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
>
> 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
>
> The PR was here, but rejected for review by the core team:
> 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/59d2de87/attachment.html>
More information about the swift-evolution
mailing list