[Review] SE-0119: Remove access modifiers from extensions

Evolution Announcements
1

Hello Swift community,

The review of "SE-0119: Remove access modifiers from extensions" begins now and runs through July 19. The proposal is available here:

  swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

  * What is your evaluation of the proposal?

-1 Strong.

This proposal should go back to the drawing board because it is incoherent.

This proposal claims to try to remove access modifiers but then also is trying to add them for:

  2.Allow access modifier when type-inheritance-clause is present.
  3 Access modifier on extensions should respect the modifier of the extended type and the protocol to which it should conform.

First it claims to remove them, then it claims to add them (2) and finally enforce them (3).

Not to mentioned the proposed solution now has rules for enforce addition of modifiers (3).

There is more adding than removing. I don’t understand the benefit here.

" If you extend a private type, any new type members you add will have a default access level of private".

This is not longer accurate with the new definition of private. Top level extensions will have default access of fileprivate.

  * Is the problem being addressed significant enough to warrant a change to Swift?

no. I was never confused by access level on extensions. I don’t think this fixes anything but on the contrary.

I don’t understand what the real problem this proposal is trying to address.

  * Does this proposal fit well with the feel and direction of Swift?

nope. It takes away a really cool feature and adds weird rules.

I think extensions are special and they should be treated as so.

If I want to extend a type as private, let me mark the extension as private and treat the extension score as private.

These rules are also going to force programers to write fileprivate a lot more often .

private extension MyType {
  func1(){}
  func2(){}
}

with this proposal:

[MyType’s access level] extension MyType {
  fileprivate func1(){}
  fileprivate func2(){}
}

What if my type is internal? Now I have to write internal all the time.

internal extension MyTyep{}

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

participated in the original thread.

3

   * What is your evaluation of the proposal?

-1. I'd like to split my review of this proposal in its two features:

The loss of extensions as an access modifier grouping construct is what I really dislike. IMHO, extensions are a natural way to express that, and I wouldn't want to have `group` to achieve the same results.

But being explicit about the access of a protocol conformance seems like a nice feature to me. But not enough to warrant the above loss.

   * Is the problem being addressed significant enough to warrant a change to Swift?

I'm not sure the problem really warrants a change.

   * Does this proposal fit well with the feel and direction of Swift?

I don't think so. I have the impression it makes the rules more complicated.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Serious read.

4

[Proposal: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub ]

Hi, Adrian. I have to agree with everyone else that the proposal is unclear. “Remove access modifiers from extensions” sounds like you just aren’t allowed to write them at all, but your proposal seems to be more “access modifiers on extensions set a maximum level of access for members, like they do for types, and do not change the default”. (Plus a bit about conformances.)

I am against the latter proposal because I don’t think people should think of extensions as first-class entities. There is really no such thing as a “public extension” or a “private extension” because extensions cannot be referred to in the language and do not have any run-time representation. The access control that really matters is that of the original type, and I wouldn’t want to force people to repeat it here.

I am personally all right with the idea of removing access modifiers from extensions altogether, but I know several people like that feature a lot, and I don’t think it passes the criterion of being “a significant enough problem to warrant a change in Swift”.

Jordan

5

        * What is your evaluation of the proposal?

-1. I think the proposal has great technical merit; if implemented, it
would improve the developer experience and pave the way for other
improvements in expressivity in the future. However, the proposal doesn't
do what it says on the tin (aka in the title), and it fails to explain the
motivation behind it or the rationale for the specific solution proposed.
My first reaction on reading it was exactly the same as that of Jose Cheyo
Jimenez, because it seemed not to do what it advertised at all. Since input
from the community is important, a proposal that doesn't explain the
problem or solution adequately can't be subjected to the scrutiny it needs
before implementation, and unfortunately I'll have to give it a thumbs-down.

        * Is the problem being addressed significant enough to warrant a

change to Swift?

There is a problem to be addressed, and I think that problem is
significant. However, it's not really explained in the proposal.

        * Does this proposal fit well with the feel and direction of Swift?

Potentially.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

I have not.

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I thought about this in-depth and participated in the original discussion
about revisions to SE-0025 that revised how access levels are treated for
classes, structs, and enums.

6

Proposal link: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

  * What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of Swift: Implicit to the type you are extending, and you can either / both declare as part of the extension declaration or on the method. I don’t see how this is confusing, and I expect people will be more confused that extensions don’t follow the convention of the rest of Swift for Access Control.

  * Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think this warrants a change.

  * Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A reading of the proposal.

7

Proposal link: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

  * What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of Swift: Implicit to the type you are extending, and you can either / both declare as part of the extension declaration or on the method. I don’t see how this is confusing, and I expect people will be more confused that extensions don’t follow the convention of the rest of Swift for Access Control.

So, actually, the proposal is correct that extensions (at least once fileprivate/private is implemented) don't follow the access control rules for the rest of Swift. There is a problem to be addressed. However, I agree that this proposal hasn't identified the issue or adequately explained how the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They look similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension.

This is easy to explain to someone new.

···

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:

This is an inconsistency that may (and IMO, really is) worth addressing. If there's adequate interest, I can circulate a draft with a proposed solution I have in mind.

  * Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think this warrants a change.

  * Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

As Jordan mentioned, I don't (and I think other people don't) think of extensions as their own entities, as they can't be referred to and have no runtime representation. In that mental model, there isn't such a thing as "an extension being public." Instead, the access modifier is just a shorthand default for the properties and methods it contains, which is teachable but unique to extensions. It is a matter of opinion whether that uniqueness is a feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about the nature of extensions.

John.

···

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Proposal link: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

  * What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of Swift: Implicit to the type you are extending, and you can either / both declare as part of the extension declaration or on the method. I don’t see how this is confusing, and I expect people will be more confused that extensions don’t follow the convention of the rest of Swift for Access Control.

So, actually, the proposal is correct that extensions (at least once fileprivate/private is implemented) don't follow the access control rules for the rest of Swift. There is a problem to be addressed. However, I agree that this proposal hasn't identified the issue or adequately explained how the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They look similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension.

This is easy to explain to someone new.

This is an inconsistency that may (and IMO, really is) worth addressing. If there's adequate interest, I can circulate a draft with a proposed solution I have in mind.

  * Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think this warrants a change.

  * Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

Proposal link:
swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

* What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of
Swift: Implicit to the type you are extending, and you can either / both
declare as part of the extension declaration or on the method. I don’t see
how this is confusing, and I expect people will be more confused that
extensions don’t follow the convention of the rest of Swift for Access
Control.

So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

This is an inconsistency that may (and IMO, really is) worth addressing. If
there's adequate interest, I can circulate a draft with a proposed solution
I have in mind.

···

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote:

* Is the problem being addressed significant enough to warrant a change to
Swift?

I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

* If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

No.

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

As Jordan mentioned, I don't (and I think other people don't) think of
extensions as their own entities, as they can't be referred to and have no
runtime representation. In that mental model, there isn't such a thing as
"an extension being public." Instead, the access modifier is just a
shorthand default for the properties and methods it contains, which is
teachable but unique to extensions. It is a matter of opinion whether that
uniqueness is a feature or a bug.

···

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal link:
swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

* What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of
Swift: Implicit to the type you are extending, and you can either / both
declare as part of the extension declaration or on the method. I don’t see
how this is confusing, and I expect people will be more confused that
extensions don’t follow the convention of the rest of Swift for Access
Control.

So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They look
similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The
default scope inside the extension is that of the "modifier" keyword on the
extension.

This is easy to explain to someone new.

This is an inconsistency that may (and IMO, really is) worth addressing.
If there's adequate interest, I can circulate a draft with a proposed
solution I have in mind.

* Is the problem being addressed significant enough to warrant a change
to Swift?

I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

* If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

No.

* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

Am 13. Juli 2016 um 18:49:11, Jordan Rose (jordan_rose@apple.com) schrieb:

Hi, Adrian. I have to agree with everyone else that the proposal is unclear. “Remove access modifiers from extensions” sounds like you just aren’t allowed to write them at all, but your proposal seems to be more “access modifiers on extensions set a maximum level of access for members, like they do for types, and do not change the default”. (Plus a bit about conformances.)
I probably misunderstood you in the original proposal thread here: [swift-evolution] [Proposal] Revising access modifiers on extensions

I renamed the proposal by thinking that would be the correct technical issue I was addressing. I apologize for any confusion the title have caused.

I am against the latter proposal because I don’t think people should think of extensions as first-class entities. There is really no such thing as a “public extension” or a “private extension” because extensions cannot be referred to in the language and do not have any run-time representation. The access control that really matters is that of the original type, and I wouldn’t want to force people to repeat it here.
Just for the record:

- What happens under the hood if I extend a specific type?

- Do you create only one single `extension bag` and sort members by the access modifiers from all different extensions?

- How do these members reference to other extensions members which are visible only inside a specific extension?

I am personally all right with the idea of removing access modifiers from extensions altogether, but I know several people like that feature a lot, and I don’t think it passes the criterion of being “a significant enough problem to warrant a change in Swift”.
I don’t mind if the proposal gets rejected now, at least I’ve seen a bit more feedback now.

PS: One think I might still would want to solve with this proposal is the default access modifier on extensions with protocols.

If you’d think about the rules in the proposed solution, aren’t they exactly how a default access modifier still can be present when there is conformance involved?

12

If it’s possible I’d like to withdraw this proposal. I’m convinced by the feedback from the community. Feel free to reject it. ;)

···

--
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution (swift-evolution@swift.org) schrieb:

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
As Jordan mentioned, I don't (and I think other people don't) think of extensions as their own entities, as they can't be referred to and have no runtime representation. In that mental model, there isn't such a thing as "an extension being public." Instead, the access modifier is just a shorthand default for the properties and methods it contains, which is teachable but unique to extensions. It is a matter of opinion whether that uniqueness is a feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about the nature of extensions.

John.

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:
Proposal link: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

* What is your evaluation of the proposal?
-1. Extensions appear to me to follow the access control of the rest of Swift: Implicit to the type you are extending, and you can either / both declare as part of the extension declaration or on the method. I don’t see how this is confusing, and I expect people will be more confused that extensions don’t follow the convention of the rest of Swift for Access Control.

So, actually, the proposal is correct that extensions (at least once fileprivate/private is implemented) don't follow the access control rules for the rest of Swift. There is a problem to be addressed. However, I agree that this proposal hasn't identified the issue or adequately explained how the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They look similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension.

This is easy to explain to someone new.

This is an inconsistency that may (and IMO, really is) worth addressing. If there's adequate interest, I can circulate a draft with a proposed solution I have in mind.

* Is the problem being addressed significant enough to warrant a change to Swift?
I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?
No. This seems to go against the direction of Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
No.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

Like others, I do find the details of this proposal hard to follow. It doesn’t seem like a simpler mental model for developers.

However, I also find the current rules around extension access modifiers hard to follow. It’s confusing that “public extension” changes the default for members, when “public class” and “public struct” don’t. And this is not ideal:

extension String: Fungible // Extension not “public”, but the conformance is public?

IMO, every public API commitment a module makes should include the word “public” at the declaration site.

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.

Cheers, P

···

On Jul 16, 2016, at 11:36 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

If it’s possible I’d like to withdraw this proposal. I’m convinced by the feedback from the community. Feel free to reject it. ;)

--
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As Jordan mentioned, I don't (and I think other people don't) think of extensions as their own entities, as they can't be referred to and have no runtime representation. In that mental model, there isn't such a thing as "an extension being public." Instead, the access modifier is just a shorthand default for the properties and methods it contains, which is teachable but unique to extensions. It is a matter of opinion whether that uniqueness is a feature or a bug.

I would say that it's interesting but ultimately not worth the confusion about the nature of extensions.

John.

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo@masters3d.com <mailto:cheyo@masters3d.com>> wrote:

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Proposal link: swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

* What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of Swift: Implicit to the type you are extending, and you can either / both declare as part of the extension declaration or on the method. I don’t see how this is confusing, and I expect people will be more confused that extensions don’t follow the convention of the rest of Swift for Access Control.

So, actually, the proposal is correct that extensions (at least once fileprivate/private is implemented) don't follow the access control rules for the rest of Swift. There is a problem to be addressed. However, I agree that this proposal hasn't identified the issue or adequately explained how the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They look similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The default scope inside the extension is that of the "modifier" keyword on the extension.

This is easy to explain to someone new.

This is an inconsistency that may (and IMO, really is) worth addressing. If there's adequate interest, I can circulate a draft with a proposed solution I have in mind.

* Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

14

I agree. I'll post a draft of a proposal surrounding this topic shortly :)

···

On Sat, Jul 16, 2016 at 12:09 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote:

Like others, I do find the details of this proposal hard to follow. It
doesn’t seem like a simpler mental model for developers.

However, I also find the *current* rules around extension access
modifiers hard to follow. It’s confusing that “public extension” changes
the default for members, when “public class” and “public struct” don’t. And
this is not ideal:

extension String: Fungible // Extension not “public”, but the
conformance is public?

IMO, every public API commitment a module makes should include the word
“public” at the declaration site.

Because of all this, I have stopped using extension-level access modifiers
altogether, instead always specifying access at the member level. I would
be interested in a proposal to improve the current model — perhaps, for
example, making “public extension” apply only to a protocol conformance,
and disabling access modifiers on extensions that don’t have a protocol
conformance.

Cheers, P

On Jul 16, 2016, at 11:36 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

If it’s possible I’d like to withdraw this proposal. I’m convinced by the
feedback from the community. Feel free to reject it. ;)
--
Adrian Zubarev
Sent with Airmail

Am 13. Juli 2016 um 19:33:00, John McCall via swift-evolution (
swift-evolution@swift.org) schrieb:

On Jul 13, 2016, at 10:26 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
As Jordan mentioned, I don't (and I think other people don't) think of
extensions as their own entities, as they can't be referred to and have no
runtime representation. In that mental model, there isn't such a thing as
"an extension being public." Instead, the access modifier is just a
shorthand default for the properties and methods it contains, which is
teachable but unique to extensions. It is a matter of opinion whether that
uniqueness is a feature or a bug.

I would say that it's interesting but ultimately not worth the confusion
about the nature of extensions.

John.

On Wed, Jul 13, 2016 at 12:19 Jose Cheyo Jimenez <cheyo@masters3d.com> > wrote:

On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:

On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution < >> swift-evolution@swift.org> wrote:

Proposal link:
swift-evolution/0119-extensions-access-modifiers.md at master · apple/swift-evolution · GitHub

* What is your evaluation of the proposal?

-1. Extensions appear to me to follow the access control of the rest of
Swift: Implicit to the type you are extending, and you can either / both
declare as part of the extension declaration or on the method. I don’t see
how this is confusing, and I expect people will be more confused that
extensions don’t follow the convention of the rest of Swift for Access
Control.

So, actually, the proposal is correct that extensions (at least once
fileprivate/private is implemented) don't follow the access control rules
for the rest of Swift. There is a problem to be addressed. However, I agree
that this proposal hasn't identified the issue or adequately explained how
the solution solves it. Here's the problem I'm thinking of:

public struct foo {
  func frobnicate() { } // implicitly internal
}

public struct bar { }
public extension bar {
  func frobnicate() { } // implicitly public
  // at least, according to the revised rules explained in SE-0025
}

There is definitely a difference, I think that is a good thing. They
look similar but they are completely different.

public Type // the type is public
public extension Type // the extension is public

For extensions, public is just a modifier on extension, not the type. The
default scope inside the extension is that of the "modifier" keyword on the
extension.

This is easy to explain to someone new.

This is an inconsistency that may (and IMO, really is) worth addressing.
If there's adequate interest, I can circulate a draft with a proposed
solution I have in mind.

* Is the problem being addressed significant enough to warrant a change
to Swift?

I don’t think this warrants a change.

* Does this proposal fit well with the feel and direction of Swift?

No. This seems to go against the direction of Swift.

* If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

No.

* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A reading of the proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

15

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, because you could extend your type with an internal protocol, or the extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.

16

To me this is reminicent of what is happening with the T.Type / Type<T> story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

···

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, because you could extend your type with an internal protocol, or the extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

17

+1 from me. While I understand that this is convenient for some, I think
that the access modifier being separate from each specific
declaration/definition leads to issues stemming from the implicit
attributes.

···

On Sat, Jul 16, 2016 at 1:15 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be
forced to write access modifier on member level. That’s what I had in my
mind all the time. But the respond on this was, as you can see purely
negative. :D

Making all extensions public when there is protocol conformance makes no
sense, because you could extend your type with an internal protocol, or the
extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers
altogether, instead always specifying access at the member level. I would
be interested in a proposal to improve the current model — perhaps, for
example, making “public extension” apply only to a protocol conformance,
and disabling access modifiers on extensions that don’t have a protocol
conformance.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Wrong thread ;) If you think it’s ill-prepared than provide some feedback instead of just watching and waiting to throw negative feedback during review process.

There is a lot done, but it’s not visible to the public thread yet. Will be soon (by tomorrow I’d guess).

Thanks.

···

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

To me this is reminicent of what is happening with the T.Type / Type<T> story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, because you could extend your type with an internal protocol, or the extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

19

Regards
(From mobile)

Wrong thread ;) If you think it’s ill-prepared than provide some feedback instead of just watching and waiting to throw negative feedback during review process.

There is a lot done, but it’s not visible to the public thread yet. Will be soon (by tomorrow I’d guess).

Thanks.

A question i regularly ponder on with modern opensource is how it went so fast from stallman writting gcc to today's anything-goes, where there seems to be an expectatation that throwing even the worst unfinished piece of code in the public should implicitely gag others, and only compel them to have to fix it.
There has always been great as well as ludicrous ideas in the history of mankind, and it would be a rare privilege of the opensource movement that the latter ought not to be singled out as such, and have them become by their mere presence in the public, everyone's responsibility to improve upon.
This proposal was based on a lack of understanding of extensions. My understand of the process is that the initial discussion phase is there to evaluate an idea leaving, only the promissing ones reach proposal stage.

···

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalkovic@gmail.com) schrieb:

To me this is reminicent of what is happening with the T.Type / Type<T> story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be forced to write access modifier on member level. That’s what I had in my mind all the time. But the respond on this was, as you can see purely negative. :D

Making all extensions public when there is protocol conformance makes no sense, because you could extend your type with an internal protocol, or the extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers altogether, instead always specifying access at the member level. I would be interested in a proposal to improve the current model — perhaps, for example, making “public extension” apply only to a protocol conformance, and disabling access modifiers on extensions that don’t have a protocol conformance.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

20

Can you elaborate? What understanding of extensions is lacking in this
proposal?

···

On Sat, Jul 16, 2016 at 22:30 L. Mihalkovic via swift-evolution < swift-evolution@swift.org> wrote:

Regards
(From mobile)

On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

Wrong thread ;) If you think it’s ill-prepared than provide some feedback
instead of just watching and waiting to throw negative feedback during
review process.

There is a lot done, but it’s not visible to the public thread yet. Will
be soon (by tomorrow I’d guess).

Thanks.

A question i regularly ponder on with modern opensource is how it went so
fast from stallman writting gcc to today's anything-goes, where there seems
to be an expectatation that throwing even the worst unfinished piece of
code in the public should implicitely gag others, and only compel them to
have to fix it.
There has always been great as well as ludicrous ideas in the history of
mankind, and it would be a rare privilege of the opensource movement that
the latter ought not to be singled out as such, and have them become by
their mere presence in the public, everyone's responsibility to improve
upon.
This proposal was based on a lack of understanding of extensions. My
understand of the process is that the initial discussion phase is there to
evaluate an idea leaving, only the promissing ones reach proposal stage.

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalkovic@gmail.com)
schrieb:

To me this is reminicent of what is happening with the T.Type / Type<T>
story, where there seems to be a rush to throw a proposal under the cut-off
date even if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

I tried to tackle the ability to write extensions where everyone would be
forced to write access modifier on member level. That’s what I had in my
mind all the time. But the respond on this was, as you can see purely
negative. :D

Making all extensions public when there is protocol conformance makes no
sense, because you could extend your type with an internal protocol, or the
extended type might be not public.

Anyways, I’m withdrawing this proposal. :)

--
Adrian Zubarev
Sent with Airmail

Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantrell@pobox.com) schrieb:

Because of all this, I have stopped using extension-level access modifiers
altogether, instead always specifying access at the member level. I would
be interested in a proposal to improve the current model — perhaps, for
example, making “public extension” apply only to a protocol conformance,
and disabling access modifiers on extensions that don’t have a protocol
conformance.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution