[swift-evolution] [Proposal] Revising access modifiers on extensions

[L. Mihalkovic]

There was an exchange in the past on how extensions are very different from swift nominal/structural types, and Doug even shared how adding scoping to extensions is not a trivial task by a long shot. In this context, talking about unifying modifier behaviors does not make much sense to me. I am not sure i understand what motivates this change.
Regards
(From mobile)

> On Jun 26, 2016, at 8:59 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Proposal is moved to a git repo: https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/nnnn-extensions-access-modifiers.md
> 
> I also updated a few things for readability.
> Revising access modifiers on extensions
> 
> Proposal: SE-NNNN
> Author: Adrian Zubarev
> Status: Awaiting review
> Review manager: TBD
> Introduction
> 
> One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.
> 
> Swift-evolution thread: [Proposal] Revising access modifiers on extensions
> 
> Motivation
> 
> When declaring members on extensions which don’t have an explicit access modifier in Swift 2.2, it is possible to create an implicitly public extension by applying a public modifier to at least one extension member.
> 
> public struct A { … }
> 
> // Implicitly public  
> extension A {
>     public var member1: SomeType { … }
>      
>     // Implicitly internal  
>     func member2() { … }
> }
> 
> // Implicitly internal
> extension A {
> 
>     // Implicitly internal
>     var member3: SomeType { … }
> }
> Furthermore in Swift 2.2 it is not allowed to apply an access modifier on extensions when a type inheritance clause is present:
> 
> public protocol B { … }
> 
> // 'public' modifier cannot be used with
> // extensions that declare protocol conformances
> public extension A : B { … }
> Proposed solution
> 
> Allow access modifier on extensions when a type inheritance clause is present.
> 
> Remove the behavior of an implicit public extension.
> 
> This changes should make access modifier on extensions consistent to classes, structs and enums (and SE–0025).
> 
> The current grammar will not change:
> 
> extension-declaration → access-level-modifieropt extension type-identifier type-inheritance-clauseopt extension-body
> 
> extension-declaration → access-level-modifieropt extension type-identifier requirement-clause extension-body
> 
> extension-body → { declarationsopt }
> 
> Iff the access-level-modifier is not present, the access modifier on extensions should always be implicitly internal.
> 
> Impact on APIs:
> 
> Current version:
> 
> /// Implementation version
> ///========================
> 
> public protocol Y {
>     func member()
> }
> 
> public struct X { … }
> 
> // Implicitly public
> extension X : Y {
>     public func member() { ... }
>      
>     // Implicitly internal
>     func anotherMember() { ... }
> }
> 
> /// Imported modele version
> ///========================
> 
> public protocol Y {
>     func member()
> }
> 
> public struct X { ... }
> 
> // Missing `public` modifier
> extension X : Y {
>     public func member() { ... }
> }
> New Version:
> 
> /// Implementation version
> ///========================
> 
> public extension X : Y {
>     public func member() { ... }
>      
>     // Implicitly internal  
>     func anotherMember() { ... }
> }
> 
> /// Imported modele version
> ///========================
> 
> public extension X : Y {
>     public func member() { ... }
> }
> Impact on existing code
> 
> This is a source-breaking change that can be automated by a migrator, by simply scanning the extension-body for at least one public modifier on its members. Iff a public modifier was found on any member, the migrator can add an explicit public modifier to the extension itself.
> 
> Alternatives considered
> 
> No other alternative were considered for this proposal.
> Rationale
> 
> On [Date], the core team decided to (TBD) this proposal. When the core team makes a decision regarding this proposal, their rationale for the decision will be written here.
> 
> 
> 
> 
> _______________________________________________
> 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/20160627/a4333c10/attachment.html>