[swift-evolution] [Proposal] Nested extensions

[Xiaodi Wu]

As I've mentioned three or four times already on this list, every time this
issue is brought up, the rules of access modifiers as revised in SE-0025
*cannot accommodate* non-top level extensions.

This is because an extension is not--and the core team is not willing to
change this despite several draft proposals--a first-class entity. The
access modifier for an extension indicates the default visibility for its
members but is not an upper bound, because a non-entity cannot bound its
members. Instead, it is an error to include anything with a higher access
modifier inside an extension.

The way this works with "private extension" is that enclosed members are
"fileprivate" by default. This only works because an extension is
guaranteed to be top level, and thus private is equal to fileprivate.

If an extension is not top level, then there is no way to spell the default
access level of a modifier inside a private extension. Therefore, the rules
for access modifiers in extensions need to be changed in order for your
proposal to be viable. You must detail how you propose to change them. I
should add, previous attempts to do so during the end of Swift 3 evolution
were not even allowed to come to review.


On Fri, Apr 14, 2017 at 04:40 Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#introduction>
> Introduction
>
> By removing the restriction that extensions can only be used as top-level
> declarations, this important feature of Swift could become more powerful
> and solve issues some users have with access control.
>
> Swift-evolution thread: Enhancing access levels without breaking changes
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035319.html>
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#motivation>
> Motivation
>
> Currently, access control is a very hot topic for Swift, and all of the
> options discussed so far had strong resistance from different parts of the
> community.
>
> This concept tries to avoid all objections that were raised against the
> various modells (of course, it triggers fresh ones at the same time ;-),
> and because it is purely additive, it removes the pressure to address the
> current issues in Swift 4. Although it wasn't a motivation, the proposal
> also offers an answer to the question if (and how) properties should be
> allowed in extensions.
>
> SE-0169 would render major parts of this idea useless, so I think it's
> qualified to be discussed in this stage.
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#proposed-solution>Proposed
> solution
>
> Simply remove the restriction that extensions can only be declared on
> top-level of a file.
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#detailed-design>Detailed
> design
>
> There isn't much to add here: Extensions should be allowed in type
> declarations and other extensions (I'm skipping methods in this draft - I
> see neither big problems associated with extensions declared inside
> methods, nor convincing use cases for them).
>
>    -
>
>    The rules should be the same as for nested types, so marking a member
>    of an extension private would restrict its visiblity to the scope of this
>    extension.
>    -
>
>    The goals of SE-0169 could be achieved in this model by simply putting
>    an extension inside a type declaration, while keeping private members
>    protected.
>
> Nested extensions should also be allowed to contain stored properties of
> the enclosing class, thus enabling better visibility management for those
> as well:
>
>    -
>
>    Stored properties in extensions have been requested before, but this
>    approach enables them quite naturally, as the rule that you can only
>    declare stored properties inside the declaration of a type is respected.
>    -
>
>    It would also be possible to levearage the "default access level"
>    feature of extensions to group properties that should have the same
>    visibility.
>
> Because there is no natural limit of nesting extensions, this feature
> enables developers to design more sophisticated systems of access rights,
> without increasing Swifts complexity for users that are happy with
> "puplic-internal-private" and don't see the need for additional keywords or
> other changes in the language.
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#future-enhancements>Future
> enhancements
>
> For extensions of an enclosing type, that type could be easily inferred,
> so some repetition could be eliminated easily.
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#source-compatibility>Source
> compatibility
>
> Purely additive
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#effect-on-abi-stability>Effect
> on ABI stability
>
> There are some pitfalls associated with ABI, but I don't think its
> stability would be affected.
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#effect-on-api-resilience>Effect
> on API resilience
>
> Nono known
>
> <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#alternatives-considered>Alternatives
> considered
>
> SE-0169, SE-0159, renaming "fileprivate" and/or "private"
> All of those possibilities have their own strengths and weaknesses, and
> there is a huge dissent which of those are important: No matter which would
> be choosen, at least one group of Swift users is punished.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170414/31d43b8b/attachment.html>