Enhancing access levels without breaking changes

SE-0169 is under active review, and is about expanding the meaning of scope to include extensions in the same file. The last day of the review period is today.

What is this about yet another change?

SE-0169 appears to say that extensions in the same file should not have access to each other's members if they are not in the same file as the type declaration. Some reviewers have specifically objected to that clause as counter to the overall design of SE-0169. Most reviewers appear to have overlooked it. I have not seen any specific support for that clause that was not tied to overall disapproval of SE-0169.

The Core Team often changes minor things like this by fiat after review; swift-evolution is not a legislative process where every last detail needs formal approval. We'll have to talk about it if we decide to accept SE-0169.

John.

···

On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
We’re not talking about the same proposal. I’m talking about SE-0169

On 11 Apr 2017, at 19:49, Daniel Duan <daniel@duan.org <mailto:daniel@duan.org>> wrote:

This never went into a review. The pull request is still open Reduce with inout by chriseidhof · Pull Request #587 · apple/swift-evolution · GitHub

On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I don't want to make any change until Chris has been able to chime in. If he agrees with us, what should be done?

• Immediate change in the proposal?
• Would it have to go through a new review?
• Or can the Core Team make the change if it is accepted?

On 11 Apr 2017, at 19:01, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 11 Apr 2017, at 16:27, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

Sent from my iPad

On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 11 Apr 2017, at 13:29, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 11 Apr 2017, at 09:40, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:

On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPhone
On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I have not voted in favor or against the proposal. I have been reading a lot of responses but I agree with Tony.

When I started reading the proposal everything was more or less fine half way through the proposal because it was reverting private to fileprivate between the type and its extensions within the same file. I said, if you think of the type and its extensions as a unit then it makes sense. I can explain that.

Then it started describing a different behavior among the extensions located in a file separate from the file containing the definition of the type. That just started a whole debate inside my head and I understand the passionate responses on both sides.

But then I imagined myself explaining this to someone new to Swift and it just doesn't seem right. If it becomes convoluted then that's a red flag that it does not belong in Swift.

I understand what you are saying and I wouldn't be against relaxing that requirement (not talking for Chris here).

The model would change from "Types share scopes with their extensions in the same file the type was defined" to "Types and their extensions share the same scope in each file".

Oh, I had missed that somehow. I agree that that is a very strange rule. Do you know why it was proposed that way?

We had to take a stance and Chris seemed to prefer the rule that was proposed. I didn't press because I'm sure he has reasons for preferring it that way. But I have a preference for generalizing visibility to all extensions, even to those in a different file than the type.

I think there is a technical limitation if the visibility goes beyond the compilation unit (unless whole module optimization is turned on).

I’m not suggesting visibility beyond the compilation unit. That would break the hierarchy of visibility layers: accessibility levels have always been contained in one-another and that’s why you can go from private, to fileprivate, to internal, to public, to open (but not the other way round) without the risk of any compilation error. If all scopes of a type were visible to each other (whatever the file), you could not go from private to fileprivate.

I’m talking about extensions of the same type in the same file (but in a separate file from the type) to be able to share private members:

Type.swift

struct A {
}

Other.swift

extension A {
    func foo() {
        bar()
    }
}

extension A {
    private func bar() {
    }
}

If this is not how your proposal already works I missed that aspect earlier and find it extremely perplexing (which is probably why I missed it).

It's mentioned in the Derailed design section:

This proposal does not change the behavior of extensions that are not in the same file as the type - i.e., extensions in a seperate file to the type do not share access between themselves:

But I agree this should be changed if there is no major technical reason against it.

I'm not aware of any technical reason why extensions in the same file should not have access to each other's members.

John.

It leaves scoped access working as in Swift 3 in exactly the case where it is least useful. We cannot place stored properties in any extensions, let alone extensions in a file other than the one containing the original declaration.

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

SE-0169 is under active review, and is about expanding the meaning of scope
to include extensions in the same file. The last day of the review period
is today.

What is this about yet another change?

···

On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution < swift-evolution@swift.org> wrote:

We’re not talking about the same proposal. I’m talking about SE-0169

On 11 Apr 2017, at 19:49, Daniel Duan <daniel@duan.org> wrote:

This never went into a review. The pull request is still open
Reduce with inout by chriseidhof · Pull Request #587 · apple/swift-evolution · GitHub

On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

I don't want to make any change until Chris has been able to chime in. If
he agrees with us, what should be done?

• Immediate change in the proposal?
• Would it have to go through a new review?
• Or can the Core Team make the change if it is accepted?

On 11 Apr 2017, at 19:01, John McCall <rjmccall@apple.com> wrote:

On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 16:27, Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPad

On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 13:29, Jonathan Hull <jhull@gbis.com> wrote:

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 09:40, John McCall <rjmccall@apple.com> wrote:

On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

Sent from my iPhone
On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution < > swift-evolution@swift.org> wrote:

I have not voted in favor or against the proposal. I have been reading a
lot of responses but I agree with Tony.

When I started reading the proposal everything was more or less fine half
way through the proposal because it was reverting private to fileprivate
between the type and its extensions within the same file. I said, if you
think of the type and its extensions as a unit then it makes sense. I can
explain that.

Then it started describing a different behavior among the extensions
located in a file separate from the file containing the definition of the
type. That just started a whole debate inside my head and I understand the
passionate responses on both sides.

But then I imagined myself explaining this to someone new to Swift and it
just doesn't seem right. If it becomes convoluted then that's a red flag
that it does not belong in Swift.

I understand what you are saying and I wouldn't be against relaxing that
requirement (not talking for Chris here).

The model would change from "Types share scopes with their extensions in
the same file the type was defined" to "Types and their extensions share
the same scope in each file".

Oh, I had missed that somehow. I agree that that is a very strange rule.
Do you know why it was proposed that way?

We had to take a stance and Chris seemed to prefer the rule that was
proposed. I didn't press because I'm sure he has reasons for preferring it
that way. But I have a preference for generalizing visibility to all
extensions, even to those in a different file than the type.

I think there is a technical limitation if the visibility goes beyond the
compilation unit (unless whole module optimization is turned on).

I’m not suggesting visibility beyond the compilation unit. That would
break the hierarchy of visibility layers: accessibility levels have always
been contained in one-another and that’s why you can go from *private*, to
*fileprivate*, to *internal*, to *public*, to *open* (but not the other
way round) without the risk of any compilation error. If all scopes of a
type were visible to each other (whatever the file), you could not go from
*private* to *fileprivate*.

I’m talking about extensions of the same type in the same file (but in a
separate file from the type) to be able to share private members:

*Type.swift*

struct A {
}

*Other.swift*

extension A {
    func foo() {
        bar()
    }
}

extension A {
    private func bar() {
    }
}

If this is not how your proposal already works I missed that aspect
earlier and find it extremely perplexing (which is probably why I missed
it).

It's mentioned in the Derailed design section:

*This proposal does not change the behavior of extensions that are not in
the same file as the type - i.e., extensions in a seperate file to the type
do not share access between themselves:*

But I agree this should be changed if there is no major technical reason
against it.

I'm not aware of any technical reason why extensions in the same file
should not have access to each other's members.

John.

It leaves scoped access working as in Swift 3 in exactly the case where it
is least useful. We cannot place stored properties in any extensions, let
alone extensions in a file other than the one containing the original
declaration.

_______________________________________________
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

Great, thanks for the clarification.

···

On Tue, Apr 11, 2017 at 14:50 John McCall <rjmccall@apple.com> wrote:

On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
SE-0169 is under active review, and is about expanding the meaning of
scope to include extensions in the same file. The last day of the review
period is today.

What is this about yet another change?

SE-0169 appears to say that extensions in the same file should not have
access to each other's members if they are not in the same file as the type
declaration. Some reviewers have specifically objected to that clause as
counter to the overall design of SE-0169. Most reviewers appear to have
overlooked it. I have not seen any specific support for that clause that
was not tied to overall disapproval of SE-0169.

The Core Team often changes minor things like this by fiat after review;
swift-evolution is not a legislative process where every last detail needs
formal approval. We'll have to talk about it if we decide to accept
SE-0169.

John.

On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

We’re not talking about the same proposal. I’m talking about SE-0169

On 11 Apr 2017, at 19:49, Daniel Duan <daniel@duan.org> wrote:

This never went into a review. The pull request is still open
Reduce with inout by chriseidhof · Pull Request #587 · apple/swift-evolution · GitHub

On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

I don't want to make any change until Chris has been able to chime in. If
he agrees with us, what should be done?

• Immediate change in the proposal?
• Would it have to go through a new review?
• Or can the Core Team make the change if it is accepted?

On 11 Apr 2017, at 19:01, John McCall <rjmccall@apple.com> wrote:

On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 16:27, Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPad

On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 13:29, Jonathan Hull <jhull@gbis.com> wrote:

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

On 11 Apr 2017, at 09:40, John McCall <rjmccall@apple.com> wrote:

On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:

Sent from my iPhone
On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution < > swift-evolution@swift.org> wrote:

I have not voted in favor or against the proposal. I have been reading a
lot of responses but I agree with Tony.

When I started reading the proposal everything was more or less fine half
way through the proposal because it was reverting private to fileprivate
between the type and its extensions within the same file. I said, if you
think of the type and its extensions as a unit then it makes sense. I can
explain that.

Then it started describing a different behavior among the extensions
located in a file separate from the file containing the definition of the
type. That just started a whole debate inside my head and I understand the
passionate responses on both sides.

But then I imagined myself explaining this to someone new to Swift and it
just doesn't seem right. If it becomes convoluted then that's a red flag
that it does not belong in Swift.

I understand what you are saying and I wouldn't be against relaxing that
requirement (not talking for Chris here).

The model would change from "Types share scopes with their extensions in
the same file the type was defined" to "Types and their extensions share
the same scope in each file".

Oh, I had missed that somehow. I agree that that is a very strange rule.
Do you know why it was proposed that way?

We had to take a stance and Chris seemed to prefer the rule that was
proposed. I didn't press because I'm sure he has reasons for preferring it
that way. But I have a preference for generalizing visibility to all
extensions, even to those in a different file than the type.

I think there is a technical limitation if the visibility goes beyond the
compilation unit (unless whole module optimization is turned on).

I’m not suggesting visibility beyond the compilation unit. That would
break the hierarchy of visibility layers: accessibility levels have always
been contained in one-another and that’s why you can go from *private*, to
*fileprivate*, to *internal*, to *public*, to *open* (but not the other
way round) without the risk of any compilation error. If all scopes of a
type were visible to each other (whatever the file), you could not go from
*private* to *fileprivate*.

I’m talking about extensions of the same type in the same file (but in a
separate file from the type) to be able to share private members:

*Type.swift*

struct A {
}

*Other.swift*

extension A {
    func foo() {
        bar()
    }
}

extension A {
    private func bar() {
    }
}

If this is not how your proposal already works I missed that aspect
earlier and find it extremely perplexing (which is probably why I missed
it).

It's mentioned in the Derailed design section:

*This proposal does not change the behavior of extensions that are not in
the same file as the type - i.e., extensions in a seperate file to the type
do not share access between themselves:*

But I agree this should be changed if there is no major technical reason
against it.

I'm not aware of any technical reason why extensions in the same file
should not have access to each other's members.

John.

It leaves scoped access working as in Swift 3 in exactly the case where it
is least useful. We cannot place stored properties in any extensions, let
alone extensions in a file other than the one containing the original
declaration.

_______________________________________________
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