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).
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
