Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

> On Apr 12, 2017, at 6:09 AM, Ricardo Parada  wrote:
> 
> 
> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> On Apr 11, 2017, at 10:30 PM, David Hart > > wrote:
 To me, the reason for limiting it to a file is about predictability, the 
 ability to locally reason about a type, and the need to define some 
 boundary (for symbol visibility reasons).  Saying that extensions to a 
 type have access to private members if they are in the same module is just 
 as arbitrary as limiting it to a single file, and a whole lot less useful 
 from the “reasoning about a type” perspective.
>>> 
>>> I think you misunderstand. We were talking about two extensions of a type, 
>>> in a different file from the type, to share private members between 
>>> themselves.
>>> 
>>> Doug Gregor mentioned it during the PR process and we added an example to 
>>> disallow it, but in hindsight, I think it should be allowed.
>> 
>> Ah, you’re saying:
>> 
>> a.swift:
>> struct X {}
>> 
>> b.swift:
>> extension X {
>>   private func f() {}
>> }
>> 
>> extension X {
>>   func g() { f() }
>> }
>> 
>> If so, then yes, I agree we should accept that.
>> 
>> -Chris
> 
> That would remove the objection I had. It would make the first half and the 
> second half of the proposal consistent. 

Just FYI, I revised the proposal.  It was an oversight/misunderstanding that 
the proposal indicated the previous approach:
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

-Chris


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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Ted F.A. van Gaalen via swift-evolution]

Hi,

(wrote a bit or two about this before)
For a moment, let's make the unlikely assumption that really no one has a 
problem 
with changing the next Swift version, having lexical scope as the only scope 
mechanism. . . 
which would be that each and every item is visible and accessible only inside 
the source level where it is declared,
unless of course revealed outwards with an access modifier. 
(.e.g. protected, internal, public (private would be implicit))  
Like it is in most other procedural/OOP languages.

Now, also assume that Swift has always been that way: lexical scope only.

Given this, as yet, hypothetical Swift environment, my questions are: 
Would this be feasible in Swift? 

E.g. does it constrain/conflict with current Swift language 
constructs/organisation ? 
(you can reveal items to the outside scope with access modifiers)

Side effects, technical limitations?

Am I right in thinking that Swift would be a lot easier to work with if lexical 
scope had
been there from the very beginning?

If Swift 4 would be set to lexical scope only, could the source conversion be 
automated successfully?
 E.g. by automatically adding the "internal" access modifier to all items that 
don't have an access modifier right now in Swift 3.x ? 

If all this would be possible, it would of course be a very drastic change, 
but what is it worth to finally get scope access right once and for all ?  
(imho)

The necessity of “private” or “fileprivate” keywords is by itself
a clear signal that the current access mechanism is wrong, I think. 

Very interested in your opinion, thank you.
Anyone?


TedvG
www.tedvg.com




> 
> Date: Wed, 12 Apr 2017 07:30:04 +0200
> From: David Hart <da...@hartbit.com <mailto:da...@hartbit.com>>
> To: Chris Lattner <clatt...@nondot.org <mailto:clatt...@nondot.org>>
> Cc: swift-evolution <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>>
> Subject: Re: [swift-evolution] Enhancing access levels without
>   breakingchanges
> Message-ID: <dacd7de1-6bc6-457a-be4d-b074c7b39...@hartbit.com 
> <mailto:dacd7de1-6bc6-457a-be4d-b074c7b39...@hartbit.com>>
> Content-Type: text/plain; charset=utf-8
> 
> 
> On 12 Apr 2017, at 07:16, Chris Lattner <clatt...@nondot.org 
> <mailto:clatt...@nondot.org>> wrote:
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>>> 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.
> 
> To me, the reason for limiting it to a file is about predictability, the 
> ability to locally reason about a type, and the need to define some boundary 
> (for symbol visibility reasons).  Saying that extensions to a type have 
> access to private members if they are in the same module is just as arbitrary 
> as limiting it to a single file, and a whole lot less useful from the 
> “reasoning about a type” perspective.
> 
> I think you misunderstand. We were talking about two extensions of a type, in 
> a different file from the type, to share private members between themselves.
> Doug Gregor mentioned it during the PR process and we added an example to 
> disallow it, but in hindsight, I think it should be allowed.
> Expanding it beyond a module would require a ton of stuff to be exported that 
> otherwise wouldn’t be, and would defeat a ton of optimization potential that 
> we can’t accept.
> 
> -Chris
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Ricardo Parada via swift-evolution]

> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Apr 11, 2017, at 10:30 PM, David Hart  wrote:
>>> To me, the reason for limiting it to a file is about predictability, the 
>>> ability to locally reason about a type, and the need to define some 
>>> boundary (for symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

That would remove the objection I had. It would make the first half and the 
second half of the proposal consistent. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 12 Apr 2017, at 07:42, Chris Lattner  wrote:
> 
> On Apr 11, 2017, at 10:30 PM, David Hart  > wrote:
>>> To me, the reason for limiting it to a file is about predictability, the 
>>> ability to locally reason about a type, and the need to define some 
>>> boundary (for symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

Should we edit the proposal or let the Core Team fix it during review as John 
suggests?

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

On Apr 11, 2017, at 10:30 PM, David Hart  wrote:
>> To me, the reason for limiting it to a file is about predictability, the 
>> ability to locally reason about a type, and the need to define some boundary 
>> (for symbol visibility reasons).  Saying that extensions to a type have 
>> access to private members if they are in the same module is just as 
>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>> the “reasoning about a type” perspective.
> 
> I think you misunderstand. We were talking about two extensions of a type, in 
> a different file from the type, to share private members between themselves.
> 
> Doug Gregor mentioned it during the PR process and we added an example to 
> disallow it, but in hindsight, I think it should be allowed.

Ah, you’re saying:

a.swift:
struct X {}

b.swift:
extension X {
  private func f() {}
}

extension X {
  func g() { f() }
}

If so, then yes, I agree we should accept that.

-Chris







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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  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?

The rationale here is to propose the minimal thing that improves the (bad) 
access control situation we have today, while leaving open this direction for 
future discussion.

I’m trying to factor potentially large N*M controversy into N+M controversy.

-Chris

> 
> • 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  > wrote:
> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson >> > wrote:
>>> 
 
 
 Sent from my iPad
 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
 > wrote:
 
> 
>> On 11 Apr 2017, at 13:29, Jonathan Hull > > wrote:
>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall >> > wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
> > wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> > 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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Chris Lattner via swift-evolution]

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
 wrote:
>>> 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.

To me, the reason for limiting it to a file is about predictability, the 
ability to locally reason about a type, and the need to define some boundary 
(for symbol visibility reasons).  Saying that extensions to a type have access 
to private members if they are in the same module is just as arbitrary as 
limiting it to a single file, and a whole lot less useful from the “reasoning 
about a type” perspective.  

Expanding it beyond a module would require a ton of stuff to be exported that 
otherwise wouldn’t be, and would defeat a ton of optimization potential that we 
can’t accept.

-Chris

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Xiaodi Wu via swift-evolution]

Great, thanks for the clarification.
On Tue, Apr 11, 2017 at 14:50 John McCall  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  wrote:
>
> This never went into a review. The pull request is still open
> https://github.com/apple/swift-evolution/pull/587
>
> 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  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  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  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  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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution 
>  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 
> > wrote:
> We’re not talking about the same proposal. I’m talking about SE-0169
> 
>> On 11 Apr 2017, at 19:49, Daniel Duan > > wrote:
>> 
>> This never went into a review. The pull request is still open 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>>> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>>> > 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 >> > wrote:
>>> 
 
> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
> > wrote:
> 
> 
> 
> On 11 Apr 2017, at 16:27, Matthew Johnson  > wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull > wrote:
 
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> > wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> > 
>>> wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> > 
>>> 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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Xiaodi Wu via 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  wrote:
>
> This never went into a review. The pull request is still open
> https://github.com/apple/swift-evolution/pull/587
>
> 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  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  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  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  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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

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

> On 11 Apr 2017, at 19:49, Daniel Duan  wrote:
> 
> This never went into a review. The pull request is still open 
> https://github.com/apple/swift-evolution/pull/587 
> 
>> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>> > 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 > > wrote:
>> 
>>> 
 On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
 > wrote:
 
 
 
 On 11 Apr 2017, at 16:27, Matthew Johnson > wrote:
 
> 
> 
> Sent from my iPad
> 
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
> > wrote:
> 
>> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull >> > wrote:
>>> 
 
 On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
 > wrote:
 
 On 11 Apr 2017, at 09:40, John McCall > wrote:
 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>> > 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 {
>> 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  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?
This is major change. I would hope for a new review if the proposal is being 
accepted. 

I would also want this new behavior to be explicit thus making it a non 
breaking change. 
 
> • Or can the Core Team make the change if it is accepted?
> 
>> On 11 Apr 2017, at 19:01, John McCall  wrote:
>> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>>> 
 
 
 Sent from my iPad
 
> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  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:
>>> 
>>> 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Daniel Duan via swift-evolution]

This never went into a review. The pull request is still open 
https://github.com/apple/swift-evolution/pull/587
> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution 
>  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  > wrote:
> 
>> 
>>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> On 11 Apr 2017, at 16:27, Matthew Johnson >> > wrote:
>>> 
 
 
 Sent from my iPad
 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
 > wrote:
 
> 
>> On 11 Apr 2017, at 13:29, Jonathan Hull > > wrote:
>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall >> > wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
> > wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> > 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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

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  wrote:
> 
> 
>> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
  wrote:
 
 
>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>> 
>> 
>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>> 
 On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
  wrote:
 
 Sent from my iPhone
 On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
  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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 11 Apr 2017, at 16:27, Matthew Johnson  > wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull > wrote:
 
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> > wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> > 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 

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 16:27, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
 On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
 
 
 On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
  wrote:
 
 On 11 Apr 2017, at 09:40, John McCall  wrote:
 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>  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.

> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
>>> 
>>> 
>>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> On 11 Apr 2017, at 09:40, John McCall  wrote:
>>> 
> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  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 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 13:29, Jonathan Hull  wrote:
> 
>> 
>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>> > wrote:
>> 
>> On 11 Apr 2017, at 09:40, John McCall > > wrote:
>> 
 On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
 > wrote:
 
 Sent from my iPhone
 On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
 > 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() {
}
}


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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jonathan Hull via swift-evolution]

> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
>  wrote:
> 
> On 11 Apr 2017, at 09:40, John McCall  > wrote:
> 
>>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Sent from my iPhone
>>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>> > 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).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 11 Apr 2017, at 09:40, John McCall  wrote:
> 
>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Sent from my iPhone
>> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>>  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.

> John.
> 
>> 
>>> I agree fileprivate may be ugly to some and it may be more popular than 
>>> private. But I think fileprivate is very clear. I know what it does from 
>>> its name without having to ask. And private behaves the way private works 
>>> in other languages. 
>>> 
>>> Regards
>>> 
>>> 
 On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
  wrote:
 
 
 
 On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
>> But even outside the generated code use cases, it's nice to just be able 
>> to implement helpers or additional "convenience" conformances in 
>> separate files named appropriately (like "Type+Protocol.swift" or 
>> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
> 
> No doubt about the usefulness of having separate files with extensions 
> here
> 
>> If nothing else, nested extensions could save those who actually don't 
>> care much about such issues from another breaking change in Swift — and 
>> imho it adds consistency:
>> We can nest types, so why can't we nest extensions?
>> 
>> Because types and extensions are quite different beasts, so something 
>> that applies to one doesn't necessarily apply to the other.
> 
> I don't buy this argument at all without an objective explanation why the 
> curly braces of extensions should be treated different than the curly 
> braces of types...
 
 They shouldn't be. That's why I don't support SE-0169 either, because it 
 would allow extensions to extend the *scope* rather than the *type*, but 
 only within the same file. I think that's fundamentally broken.
 
 But my comment wasn't about curly braces—it was about types vs. 
 extensions. For example, you can declare local types within a function, 
 but you can't extend a type within a function (nor do I think it would be 
 a good idea).
 
  
> 
>> I don't think that holds its weight. This feels like another case of 
>> "let's try to satisfy everyone who's unhappy with some part of Swift 
>> visibility by changing a completely different feature to make things 
>> fall into place", which I don't think is a sound motivation or design 
>> principle. The example you posted in your initial message weaves 
>> multiple types/nesting levels together in a way that looks *incredibly* 
>> difficult to follow/parse to even an experienced user of the language.
> 
> Did you noticed that I started this example as mockery? In real life, I 
> would hopefully never nest more than once… and do you think sprinkling 
> parts of class over the project is easier to follow?
 
 Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* 
 parts of a type across the project, but if there's some kind of "aside" 
 functionality that doesn't depend on private knowledge of the type, then I 
 find it to 

Re: [swift-evolution] Enhancing access levels without breaking changes

[John McCall via swift-evolution]

> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution 
>  wrote:
> 
> Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
> > 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?

John.

> 
>> I agree fileprivate may be ugly to some and it may be more popular than 
>> private. But I think fileprivate is very clear. I know what it does from its 
>> name without having to ask. And private behaves the way private works in 
>> other languages. 
>> 
>> Regards
>> 
>> 
>> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de 
>>> > wrote:
 But even outside the generated code use cases, it's nice to just be able 
 to implement helpers or additional "convenience" conformances in separate 
 files named appropriately (like "Type+Protocol.swift" or 
 "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>>> 
>>> No doubt about the usefulness of having separate files with extensions here
>>> 
 If nothing else, nested extensions could save those who actually don't 
 care much about such issues from another breaking change in Swift — and 
 imho it adds consistency:
 We can nest types, so why can't we nest extensions?
 
 Because types and extensions are quite different beasts, so something that 
 applies to one doesn't necessarily apply to the other.
>>> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types...
>>> 
>>> They shouldn't be. That's why I don't support SE-0169 either, because it 
>>> would allow extensions to extend the *scope* rather than the *type*, but 
>>> only within the same file. I think that's fundamentally broken.
>>> 
>>> But my comment wasn't about curly braces—it was about types vs. extensions. 
>>> For example, you can declare local types within a function, but you can't 
>>> extend a type within a function (nor do I think it would be a good idea).
>>> 
>>>  
>>> 
 I don't think that holds its weight. This feels like another case of 
 "let's try to satisfy everyone who's unhappy with some part of Swift 
 visibility by changing a completely different feature to make things fall 
 into place", which I don't think is a sound motivation or design 
 principle. The example you posted in your initial message weaves multiple 
 types/nesting levels together in a way that looks *incredibly* difficult 
 to follow/parse to even an experienced user of the language.
>>> 
>>> Did you noticed that I started this example as mockery? In real life, I 
>>> would hopefully never nest more than once… and do you think sprinkling 
>>> parts of class over the project is easier to follow?
>>> 
>>> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* 
>>> parts of a type across the project, but if there's some kind of "aside" 
>>> functionality that doesn't depend on private knowledge of the type, then I 
>>> find it to be a nice feature to have. It requires me to have reasonable 
>>> names to my source files, but that's not a significant burden.
>>> 
>>>  
>>> 
 Everyone seems to be striving for a "perfect" level of access control that 
 lets individual types/members dictate precisely what other types/members 
 can access them. I'm not sure if that perfection is attainable or not, but 
 even if it 

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

Sent from my iPhone
> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution 
>  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".

> I agree fileprivate may be ugly to some and it may be more popular than 
> private. But I think fileprivate is very clear. I know what it does from its 
> name without having to ask. And private behaves the way private works in 
> other languages. 
> 
> Regards
> 
> 
>> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
 But even outside the generated code use cases, it's nice to just be able 
 to implement helpers or additional "convenience" conformances in separate 
 files named appropriately (like "Type+Protocol.swift" or 
 "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>>> 
>>> No doubt about the usefulness of having separate files with extensions here
>>> 
 If nothing else, nested extensions could save those who actually don't 
 care much about such issues from another breaking change in Swift — and 
 imho it adds consistency:
 We can nest types, so why can't we nest extensions?
 
 Because types and extensions are quite different beasts, so something that 
 applies to one doesn't necessarily apply to the other.
>>> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types...
>> 
>> They shouldn't be. That's why I don't support SE-0169 either, because it 
>> would allow extensions to extend the *scope* rather than the *type*, but 
>> only within the same file. I think that's fundamentally broken.
>> 
>> But my comment wasn't about curly braces—it was about types vs. extensions. 
>> For example, you can declare local types within a function, but you can't 
>> extend a type within a function (nor do I think it would be a good idea).
>> 
>>  
>>> 
 I don't think that holds its weight. This feels like another case of 
 "let's try to satisfy everyone who's unhappy with some part of Swift 
 visibility by changing a completely different feature to make things fall 
 into place", which I don't think is a sound motivation or design 
 principle. The example you posted in your initial message weaves multiple 
 types/nesting levels together in a way that looks *incredibly* difficult 
 to follow/parse to even an experienced user of the language.
>>> 
>>> Did you noticed that I started this example as mockery? In real life, I 
>>> would hopefully never nest more than once… and do you think sprinkling 
>>> parts of class over the project is easier to follow?
>> 
>> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* parts 
>> of a type across the project, but if there's some kind of "aside" 
>> functionality that doesn't depend on private knowledge of the type, then I 
>> find it to be a nice feature to have. It requires me to have reasonable 
>> names to my source files, but that's not a significant burden.
>> 
>>  
>>> 
 Everyone seems to be striving for a "perfect" level of access control that 
 lets individual types/members dictate precisely what other types/members 
 can access them. I'm not sure if that perfection is attainable or not, but 
 even if it is, I don't think it's something we should strive for. I'd 
 rather have a simple visibility model that leaks a little than an 
 air-tight model that allows people to write overly complicated code for 
 the sake of fine-tuning access.
>>> 
>>> I had no desire to change the model of Swift 2 — but apparently, others 
>>> thought it wasn't sufficient, and I'd rather prefer a 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Ricardo Parada via swift-evolution]

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 agree fileprivate may be ugly to some and it may be more popular than 
private. But I think fileprivate is very clear. I know what it does from its 
name without having to ask. And private behaves the way private works in other 
languages. 

Regards


> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
>>> But even outside the generated code use cases, it's nice to just be able to 
>>> implement helpers or additional "convenience" conformances in separate 
>>> files named appropriately (like "Type+Protocol.swift" or 
>>> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>> 
>> No doubt about the usefulness of having separate files with extensions here
>> 
>>> If nothing else, nested extensions could save those who actually don't care 
>>> much about such issues from another breaking change in Swift — and imho it 
>>> adds consistency:
>>> We can nest types, so why can't we nest extensions?
>>> 
>>> Because types and extensions are quite different beasts, so something that 
>>> applies to one doesn't necessarily apply to the other.
>> 
>> I don't buy this argument at all without an objective explanation why the 
>> curly braces of extensions should be treated different than the curly braces 
>> of types...
> 
> They shouldn't be. That's why I don't support SE-0169 either, because it 
> would allow extensions to extend the *scope* rather than the *type*, but only 
> within the same file. I think that's fundamentally broken.
> 
> But my comment wasn't about curly braces—it was about types vs. extensions. 
> For example, you can declare local types within a function, but you can't 
> extend a type within a function (nor do I think it would be a good idea).
> 
>  
>> 
>>> I don't think that holds its weight. This feels like another case of "let's 
>>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>>> changing a completely different feature to make things fall into place", 
>>> which I don't think is a sound motivation or design principle. The example 
>>> you posted in your initial message weaves multiple types/nesting levels 
>>> together in a way that looks *incredibly* difficult to follow/parse to even 
>>> an experienced user of the language.
>> 
>> Did you noticed that I started this example as mockery? In real life, I 
>> would hopefully never nest more than once… and do you think sprinkling parts 
>> of class over the project is easier to follow?
> 
> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* parts 
> of a type across the project, but if there's some kind of "aside" 
> functionality that doesn't depend on private knowledge of the type, then I 
> find it to be a nice feature to have. It requires me to have reasonable names 
> to my source files, but that's not a significant burden.
> 
>  
>> 
>>> Everyone seems to be striving for a "perfect" level of access control that 
>>> lets individual types/members dictate precisely what other types/members 
>>> can access them. I'm not sure if that perfection is attainable or not, but 
>>> even if it is, I don't think it's something we should strive for. I'd 
>>> rather have a simple visibility model that leaks a little than an air-tight 
>>> model that allows people to write overly complicated code for the sake of 
>>> fine-tuning access.
>> 
>> I had no desire to change the model of Swift 2 — but apparently, others 
>> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
>> model like nesting over a complicated one with less power.
>> 
>>> Let's remember that the core team has limited resources to implement the 
>>> things we propose, and if I have to choose between, say, serialization, 
>>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>>> again, it's clear to me which one I would want dropped on the floor. I 
>>> don't want perfect to be the enemy of good.
>> 
>> Well, right now, there are several (at least one ;-) proposals that aim for 
>> a 

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato via swift-evolution]

On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:

> But even outside the generated code use cases, it's nice to just be able
> to implement helpers or additional "convenience" conformances in separate
> files named appropriately (like "Type+Protocol.swift" or
> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>
> No doubt about the usefulness of having separate files with extensions here
>
> If nothing else, nested extensions could save those who actually don't
> care much about such issues from another breaking change in Swift — and
> imho it adds consistency:
> We can nest types, so why can't we nest extensions?
>
>
> Because types and extensions are quite different beasts, so something that
> applies to one doesn't necessarily apply to the other.
>
> I don't buy this argument at all without an objective explanation why the
> curly braces of extensions should be treated different than the curly
> braces of types...
>

They shouldn't be. That's why I don't support SE-0169 either, because it
would allow extensions to extend the *scope* rather than the *type*, but
only within the same file. I think that's fundamentally broken.

But my comment wasn't about curly braces—it was about types vs. extensions.
For example, you can declare local types within a function, but you can't
extend a type within a function (nor do I think it would be a good idea).



>
> I don't think that holds its weight. This feels like another case of
> "let's try to satisfy everyone who's unhappy with some part of Swift
> visibility by changing a completely different feature to make things fall
> into place", which I don't think is a sound motivation or design principle.
> The example you posted in your initial message weaves multiple
> types/nesting levels together in a way that looks *incredibly* difficult to
> follow/parse to even an experienced user of the language.
>
> Did you noticed that I started this example as mockery? In real life, I
> would hopefully never nest more than once… and do you think sprinkling
> parts of class over the project is easier to follow?
>

Depending on the type, yes. I wouldn't sprinkle the *fundamental/core*
parts of a type across the project, but if there's some kind of "aside"
functionality that doesn't depend on private knowledge of the type, then I
find it to be a nice feature to have. It requires me to have reasonable
names to my source files, but that's not a significant burden.



>
> Everyone seems to be striving for a "perfect" level of access control that
> lets individual types/members dictate precisely what other types/members
> can access them. I'm not sure if that perfection is attainable or not, but
> even if it is, I don't think it's something we should strive for. I'd
> rather have a simple visibility model that leaks a little than an air-tight
> model that allows people to write overly complicated code for the sake of
> fine-tuning access.
>
> I had no desire to change the model of Swift 2 — but apparently, others
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple
> model like nesting over a complicated one with less power.
>
> Let's remember that the core team has limited resources to implement the
> things we propose, and if I have to choose between, say, serialization,
> reflection, asynchronous constructs, and rehashing visibility levels yet
> again, it's clear to me which one I would want dropped on the floor. I
> don't want perfect to be the enemy of good.
>
> Well, right now, there are several (at least one ;-) proposals that aim
> for a breaking change of the whole model… nested extensions break nothing,
> so it can be delayed for as long as the core team likes, without causing
> any trouble.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 10:22 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>>> I don't buy this argument at all without an objective explanation why the 
>>> curly braces of extensions should be treated different than the curly 
>>> braces of types…
>> Extensions are not Partials. 
>>> do you think sprinkling parts of class over the project is easier to follow?
>> Extensions are not Partials. 
> I can't see how statement and answer(?) are related to the original post… or 
> did I miss that this topic is about partials? :)
I am partial to partials. :)
> 
>>> it can be delayed for as long as the core team likes, without causing any 
>>> trouble.
>> Partials limited to the same scope can do the same
> That is true… so can we agree that nothing should change now, so that 
> something can be added later? ;-)
Same page. 
> 
>> with out having to give extension special nesting powers :)
> I would say there's no doubt that extensions are withhold the common nesting 
> powers of all other, similar constructs in Swift: Classes can be nested, 
> Structs can be nested, Enums can be nested, functions can be nested, 
> protocols… I haven't tried yet, but associated objects are something 
> comparable ;-)

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

>> I don't buy this argument at all without an objective explanation why the 
>> curly braces of extensions should be treated different than the curly braces 
>> of types…
> Extensions are not Partials. 
>> do you think sprinkling parts of class over the project is easier to follow?
> Extensions are not Partials. 
I can't see how statement and answer(?) are related to the original post… or 
did I miss that this topic is about partials? :)

>> it can be delayed for as long as the core team likes, without causing any 
>> trouble.
> Partials limited to the same scope can do the same
That is true… so can we agree that nothing should change now, so that something 
can be added later? ;-)

> with out having to give extension special nesting powers :)
I would say there's no doubt that extensions are withhold the common nesting 
powers of all other, similar constructs in Swift: Classes can be nested, 
Structs can be nested, Enums can be nested, functions can be nested, protocols… 
I haven't tried yet, but associated objects are something comparable ;-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> But even outside the generated code use cases, it's nice to just be able to 
>> implement helpers or additional "convenience" conformances in separate files 
>> named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I 
>> find it makes my codebase easier to navigate.
> No doubt about the usefulness of having separate files with extensions here
> 
>> If nothing else, nested extensions could save those who actually don't care 
>> much about such issues from another breaking change in Swift — and imho it 
>> adds consistency:
>> We can nest types, so why can't we nest extensions?
>> 
>> Because types and extensions are quite different beasts, so something that 
>> applies to one doesn't necessarily apply to the other.
> I don't buy this argument at all without an objective explanation why the 
> curly braces of extensions should be treated different than the curly braces 
> of types…
Extensions are not Partials. 
> 
>> I don't think that holds its weight. This feels like another case of "let's 
>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>> changing a completely different feature to make things fall into place", 
>> which I don't think is a sound motivation or design principle. The example 
>> you posted in your initial message weaves multiple types/nesting levels 
>> together in a way that looks *incredibly* difficult to follow/parse to even 
>> an experienced user of the language.
> Did you noticed that I started this example as mockery? In real life, I would 
> hopefully never nest more than once… and do you think sprinkling parts of 
> class over the project is easier to follow?
Extensions are not Partials. 
> 
>> Everyone seems to be striving for a "perfect" level of access control that 
>> lets individual types/members dictate precisely what other types/members can 
>> access them. I'm not sure if that perfection is attainable or not, but even 
>> if it is, I don't think it's something we should strive for. I'd rather have 
>> a simple visibility model that leaks a little than an air-tight model that 
>> allows people to write overly complicated code for the sake of fine-tuning 
>> access.
> I had no desire to change the model of Swift 2 — but apparently, others 
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
> model like nesting over a complicated one with less power.
> 
>> Let's remember that the core team has limited resources to implement the 
>> things we propose, and if I have to choose between, say, serialization, 
>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>> again, it's clear to me which one I would want dropped on the floor. I don't 
>> want perfect to be the enemy of good.
> Well, right now, there are several (at least one ;-) proposals that aim for a 
> breaking change of the whole model… nested extensions break nothing, so it 
> can be delayed for as long as the core team likes, without causing any 
> trouble.
Partials limited to the same scope can do the same with out having to give 
extension special nesting powers :)
> ___
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> But even outside the generated code use cases, it's nice to just be able to 
> implement helpers or additional "convenience" conformances in separate files 
> named appropriately (like "Type+Protocol.swift" or "Type+Helpers.swift"). I 
> find it makes my codebase easier to navigate.
No doubt about the usefulness of having separate files with extensions here

> If nothing else, nested extensions could save those who actually don't care 
> much about such issues from another breaking change in Swift — and imho it 
> adds consistency:
> We can nest types, so why can't we nest extensions?
> 
> Because types and extensions are quite different beasts, so something that 
> applies to one doesn't necessarily apply to the other.
I don't buy this argument at all without an objective explanation why the curly 
braces of extensions should be treated different than the curly braces of 
types...

> I don't think that holds its weight. This feels like another case of "let's 
> try to satisfy everyone who's unhappy with some part of Swift visibility by 
> changing a completely different feature to make things fall into place", 
> which I don't think is a sound motivation or design principle. The example 
> you posted in your initial message weaves multiple types/nesting levels 
> together in a way that looks *incredibly* difficult to follow/parse to even 
> an experienced user of the language.
Did you noticed that I started this example as mockery? In real life, I would 
hopefully never nest more than once… and do you think sprinkling parts of class 
over the project is easier to follow?

> Everyone seems to be striving for a "perfect" level of access control that 
> lets individual types/members dictate precisely what other types/members can 
> access them. I'm not sure if that perfection is attainable or not, but even 
> if it is, I don't think it's something we should strive for. I'd rather have 
> a simple visibility model that leaks a little than an air-tight model that 
> allows people to write overly complicated code for the sake of fine-tuning 
> access.
I had no desire to change the model of Swift 2 — but apparently, others thought 
it wasn't sufficient, and I'd rather prefer a conceptually simple model like 
nesting over a complicated one with less power.

> Let's remember that the core team has limited resources to implement the 
> things we propose, and if I have to choose between, say, serialization, 
> reflection, asynchronous constructs, and rehashing visibility levels yet 
> again, it's clear to me which one I would want dropped on the floor. I don't 
> want perfect to be the enemy of good.
Well, right now, there are several (at least one ;-) proposals that aim for a 
breaking change of the whole model… nested extensions break nothing, so it can 
be delayed for as long as the core team likes, without causing any trouble.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> What do you think of `partial` types like C# but limited to a file?

Well, imho it would be better than some alternatives, because it might lay the 
ground for something that is more useful than current same-file extensions, 
which offer no guarantee that the extension declaring the conformance adds 
anything to fulfil them (and because of retroactive conformance, I don't think 
this will be changed for extensions).

If private isn't restricted to a single scope anymore, imho all the splitting 
has no practical benefits at all, and even if we keep the old definition, I 
doubt that it's worth the increased complexity:
A //MARK-comment is much more useful than an extension, and like many 
developers, I prefer to keep instance variables grouped in a prominent place 
(above the methods), so most likely wouldn't use the "special power" of partial.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 10:26 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> I’m not sure that this solves anything meaningful (whether in relation to 
>> SE-0169 or more generally), does it? What advantage does this provide over 
>> just declaring the protocol conformance and those methods as a direct part 
>> of the parent type? This seems like it would just introduce more 
>> indentation, and more lines of code, for zero benefit.
> Well, I'm not overwhelmingly convinced of this whole "we put same-module 
> stuff into extensions" anyways, so it's debatable wether proposals like 
> SE-0169 have any meaningful effects at all… do you think that conformances in 
> same-file extensions have a real benefit? 

I think the primary benefit is organizational.  People like having the members 
that implement a conformance grouped together with the conformance declaration.

> 
> If nothing else, nested extensions could save those who actually don't care 
> much about such issues from another breaking change in Swift — and imho it 
> adds consistency:
> We can nest types, so why can't we nest extensions?
> ___
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> I’m not sure that this solves anything meaningful (whether in relation to 
> SE-0169 or more generally), does it? What advantage does this provide over 
> just declaring the protocol conformance and those methods as a direct part of 
> the parent type? This seems like it would just introduce more indentation, 
> and more lines of code, for zero benefit.
Well, I'm not overwhelmingly convinced of this whole "we put same-module stuff 
into extensions" anyways, so it's debatable wether proposals like SE-0169 have 
any meaningful effects at all… do you think that conformances in same-file 
extensions have a real benefit? 

If nothing else, nested extensions could save those who actually don't care 
much about such issues from another breaking change in Swift — and imho it adds 
consistency:
We can nest types, so why can't we nest extensions?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

> The one issue I see is sticking that public extension inside a private one.  
> I think you would have to mark ‘secret: Int’ as private instead of the 
> extension itself to allow the effect you are looking for…
I didn't think that much while writing the example, but this one was actually 
on purpose:
It's stated in the Swift documentation that the default visibility of members 
in an extension equals the level of the extension — so this use of extensions 
is also a way to group all public declarations (the other levels as well), and 
save some keystrokes.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato via swift-evolution]

Extensions can already do what partials would do, and more—Swift does not
need two features that are almost the same but with subtle differences when
it comes to the visibility of its members. That seems like something that
will only cause confusion for users. Partials feel like trying to shoehorn
a feature from another language into Swift to solve an unrelated problem.

Swift 2 and 3 have never had type-oriented visibility—they've only had
visibility that covered contiguous regions of the symbol space ("the
universe", "the module", "the file", and then in Swift 3, "the enclosing
scope"). Being able to split a type's *scope* with partials (as opposed to
just the type itself with extensions) across multiple files files would be
quite inconsistent with how visibility in Swift has been so far.

At some point, we need to come to grips with the fact that there are going
to be keywords we think are a little ugly (I much preferred the original
definition of "private", but "fileprivate" is part of Swift now and I've
moved on) and that there's never going to be a way to perfectly audit
visibility of every single member that we write in a way that makes
everyone happy.

I don't want to sound dismissive, but I feel like it's simply not
productive to keep rehashing visibility over and over again.


On Mon, Apr 10, 2017 at 7:20 AM Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
>
>
> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
>
> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This struck me as a bit odd at first, but the more I think about it, the
> more I really like the ability to nest extensions/scopes.  The one issue I
> see is sticking that public extension inside a private one.  I think you
> would have to mark ‘secret: Int’ as private instead of the extension itself
> to allow the effect you are looking for...
>
> What I ultimately want is the ability to declare storage in extensions in
> the same submodule. Combining that with fileprivate will allow the same
> tricks without the indentation (together in their own file).  This nesting
> will help in the mean-time (and would still be useful after for those who
> prefer to organize their code in fewer/longer files).  I think it could be
> helpful in other ways too…
>
>
> What do you think of `partial` types like C# but limited to a file?
> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>
>
> That's the direction the new proposal (0169) is going towards with
> extensions in the same file.
>
>
> I don’t see how SE-0169 do that more than any other meaning private got
> until now. This was already the case with the initial meaning of private,
> and was the case with fileprivate.
>
>
> The current semantics of private don’t give any support for partial types
> like in C# because the accessibility is restricted to the current scope.
> With SE-0169’s private, extensions in the same file as the type share that
> scope. Plus, the *Alternatives Considered* section of the proposal
> discusses potential future directions where those extensions could look
> even more like C# partials :)
>
>
> SE-169 could be emulated cleanly by introducing partial types within the *same
> scope* as a new feature completely separate from extensions. Partial
> types would not require redefining how private or extensions work now. It
> would also serve as a way to communicate to the user that the type is not
> done being defined so if they want to encapsulate the type completely, They
> have to make it non partial.
>
>
>
>
>
>
> And for file splitting and visibility control, we need submodules. Until
> then, if this proposal is to define the ultimate meaning of private, I
> rather like this meaning that the SE-0025 one.
>
>
> ___
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
>>> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
>>> 
>>> 
>>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>>>  a écrit :
>>> 
>>> 
>>> 
>>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>>>  wrote:
>>> 
 
> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> This struck me as a bit odd at first, but the more I think about it, the 
> more I really like the ability to nest extensions/scopes.  The one issue 
> I see is sticking that public extension inside a private one.  I think 
> you would have to mark ‘secret: Int’ as private instead of the extension 
> itself to allow the effect you are looking for...
> 
> What I ultimately want is the ability to declare storage in extensions in 
> the same submodule. Combining that with fileprivate will allow the same 
> tricks without the indentation (together in their own file).  This 
> nesting will help in the mean-time (and would still be useful after for 
> those who prefer to organize their code in fewer/longer files).  I think 
> it could be helpful in other ways too…
 
 What do you think of `partial` types like C# but limited to a file?
 https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
 
>>> 
>>> That's the direction the new proposal (0169) is going towards with 
>>> extensions in the same file.
>> 
>> I don’t see how SE-0169 do that more than any other meaning private got 
>> until now. This was already the case with the initial meaning of private, 
>> and was the case with fileprivate.
> 
> The current semantics of private don’t give any support for partial types 
> like in C# because the accessibility is restricted to the current scope. With 
> SE-0169’s private, extensions in the same file as the type share that scope. 
> Plus, the Alternatives Considered section of the proposal discusses potential 
> future directions where those extensions could look even more like C# 
> partials :)

SE-169 could be emulated cleanly by introducing partial types within the same 
scope as a new feature completely separate from extensions. Partial types would 
not require redefining how private or extensions work now. It would also serve 
as a way to communicate to the user that the type is not done being defined so 
if they want to encapsulate the type completely, They have to make it non 
partial. 





> 
>> And for file splitting and visibility control, we need submodules. Until 
>> then, if this proposal is to define the ultimate meaning of private, I 
>> rather like this meaning that the SE-0025 one.
>> 
> 
> ___
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 10 Apr 2017, at 08:21, Jean-Daniel  wrote:
> 
> 
>> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>> > a écrit :
>> 
>> 
>> 
>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>> > wrote:
>> 
>>> 
 On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
 > wrote:
 
 This struck me as a bit odd at first, but the more I think about it, the 
 more I really like the ability to nest extensions/scopes.  The one issue I 
 see is sticking that public extension inside a private one.  I think you 
 would have to mark ‘secret: Int’ as private instead of the extension 
 itself to allow the effect you are looking for...
 
 What I ultimately want is the ability to declare storage in extensions in 
 the same submodule. Combining that with fileprivate will allow the same 
 tricks without the indentation (together in their own file).  This nesting 
 will help in the mean-time (and would still be useful after for those who 
 prefer to organize their code in fewer/longer files).  I think it could be 
 helpful in other ways too…
>>> 
>>> What do you think of `partial` types like C# but limited to a file?
>>> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx 
>>> 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>>>  
>>> 
>>> 
>> 
>> That's the direction the new proposal (0169) is going towards with 
>> extensions in the same file.
> 
> I don’t see how SE-0169 do that more than any other meaning private got until 
> now. This was already the case with the initial meaning of private, and was 
> the case with fileprivate.

The current semantics of private don’t give any support for partial types like 
in C# because the accessibility is restricted to the current scope. With 
SE-0169’s private, extensions in the same file as the type share that scope. 
Plus, the Alternatives Considered section of the proposal discusses potential 
future directions where those extensions could look even more like C# partials 
:)

> And for file splitting and visibility control, we need submodules. Until 
> then, if this proposal is to define the ultimate meaning of private, I rather 
> like this meaning that the SE-0025 one.
> 

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jean-Daniel via swift-evolution]

> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution 
>  a écrit :
> 
> 
> 
> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
> > wrote:
> 
>> 
>>> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> 
>>> This struck me as a bit odd at first, but the more I think about it, the 
>>> more I really like the ability to nest extensions/scopes.  The one issue I 
>>> see is sticking that public extension inside a private one.  I think you 
>>> would have to mark ‘secret: Int’ as private instead of the extension itself 
>>> to allow the effect you are looking for...
>>> 
>>> What I ultimately want is the ability to declare storage in extensions in 
>>> the same submodule. Combining that with fileprivate will allow the same 
>>> tricks without the indentation (together in their own file).  This nesting 
>>> will help in the mean-time (and would still be useful after for those who 
>>> prefer to organize their code in fewer/longer files).  I think it could be 
>>> helpful in other ways too…
>> 
>> What do you think of `partial` types like C# but limited to a file?
>> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx 
>> 
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
>>  
>> 
>> 
> 
> That's the direction the new proposal (0169) is going towards with extensions 
> in the same file.

I don’t see how SE-0169 do that more than any other meaning private got until 
now. This was already the case with the initial meaning of private, and was the 
case with fileprivate.

And for file splitting and visibility control, we need submodules. Until then, 
if this proposal is to define the ultimate meaning of private, I rather like 
this meaning that the SE-0025 one.


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

Re: [swift-evolution] Enhancing access levels without breaking changes

[David Hart via swift-evolution]

> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
>> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> This struck me as a bit odd at first, but the more I think about it, the 
>> more I really like the ability to nest extensions/scopes.  The one issue I 
>> see is sticking that public extension inside a private one.  I think you 
>> would have to mark ‘secret: Int’ as private instead of the extension itself 
>> to allow the effect you are looking for...
>> 
>> What I ultimately want is the ability to declare storage in extensions in 
>> the same submodule. Combining that with fileprivate will allow the same 
>> tricks without the indentation (together in their own file).  This nesting 
>> will help in the mean-time (and would still be useful after for those who 
>> prefer to organize their code in fewer/longer files).  I think it could be 
>> helpful in other ways too…
> 
> What do you think of `partial` types like C# but limited to a file?
> https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
> 

That's the direction the new proposal (0169) is going towards with extensions 
in the same file.

> 
>> 
>> Thanks,
>> Jon
>> 
>>> On Apr 8, 2017, at 5:03 AM, Tino Heth via swift-evolution 
>>>  wrote:
>>> 
>>> Imho there is a simple solution to reach the goals of SE-0169 without 
>>> breaking compatibility:
>>> Just allow extensions inside type declarations.
>>> 
>>> class MyVC: UIViewController {
>>> private let numberOfSections = 0
>>> 
>>> extension: UITableViewDataSource {
>>> // Skipping the class and assume we want to extend the surrounding 
>>> type
>>> func numberOfSections(in tableView: UITableView) -> Int {
>>> return numberOfSections
>>> }
>>> 
>>> func tableView(_ tableView: UITableView, numberOfRowsInSection 
>>> section: Int) -> Int {
>>> return 0
>>> }
>>> }
>>> 
>>> private extension {
>>> // this would contain everything that shoudn't be visible for other 
>>> extensios
>>> 
>>> var secret: Int = 0
>>> 
>>> public extension MyFriendClass {
>>> // oh, well, I make an exception here for a trustworthy type
>>> func checkSecret(of controller: MyVC) -> Bool {
>>> return controller.secret > 0
>>> }
>>> }
>>> 
>>> private extension {
>>> // this is so secret, I'm not even allowed to copy it
>>> }
>>> }
>>> 
>>> public func myMethod() {
>>> print("This is just a boring method")
>>> }
>>> }
>>> 
>>> It has the downside of shifting code to the right (you could as well leave 
>>> those extension-blocks unindented), but lots of advantages:
>>> - No change for private needed
>>> - It can be nested as much as you like to satisfy even the most absurd 
>>> desires of encapsulation
>>> - It reminds me on operator definitions inside type declarations 
>>> - No change for fileprivate needed (but actually, I think there is very 
>>> little need to keep fileprivate)
>>> 
>>> I wish this would only be a joke, but writing the example, I actually 
>>> started liking the concept (but I have a terrible headache right now which 
>>> might affect my mind) — so either this receives some feedback, or I might 
>>> start re-proposing this ;-)
>>> 
>>> - Tino
>>> ___
>>> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> This struck me as a bit odd at first, but the more I think about it, the more 
> I really like the ability to nest extensions/scopes.  The one issue I see is 
> sticking that public extension inside a private one.  I think you would have 
> to mark ‘secret: Int’ as private instead of the extension itself to allow the 
> effect you are looking for...
> 
> What I ultimately want is the ability to declare storage in extensions in the 
> same submodule. Combining that with fileprivate will allow the same tricks 
> without the indentation (together in their own file).  This nesting will help 
> in the mean-time (and would still be useful after for those who prefer to 
> organize their code in fewer/longer files).  I think it could be helpful in 
> other ways too…

What do you think of `partial` types like C# but limited to a file?
https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx 


https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html
 




> 
> Thanks,
> Jon
> 
>> On Apr 8, 2017, at 5:03 AM, Tino Heth via swift-evolution 
>> > wrote:
>> 
>> Imho there is a simple solution to reach the goals of SE-0169 without 
>> breaking compatibility:
>> Just allow extensions inside type declarations.
>> 
>> class MyVC: UIViewController {
>> private let numberOfSections = 0
>> 
>> extension: UITableViewDataSource {
>> // Skipping the class and assume we want to extend the surrounding 
>> type
>> func numberOfSections(in tableView: UITableView) -> Int {
>> return numberOfSections
>> }
>> 
>> func tableView(_ tableView: UITableView, numberOfRowsInSection 
>> section: Int) -> Int {
>> return 0
>> }
>> }
>> 
>> private extension {
>> // this would contain everything that shoudn't be visible for other 
>> extensios
>> 
>> var secret: Int = 0
>> 
>> public extension MyFriendClass {
>> // oh, well, I make an exception here for a trustworthy type
>> func checkSecret(of controller: MyVC) -> Bool {
>> return controller.secret > 0
>> }
>> }
>> 
>> private extension {
>> // this is so secret, I'm not even allowed to copy it
>> }
>> }
>> 
>> public func myMethod() {
>> print("This is just a boring method")
>> }
>> }
>> 
>> It has the downside of shifting code to the right (you could as well leave 
>> those extension-blocks unindented), but lots of advantages:
>> - No change for private needed
>> - It can be nested as much as you like to satisfy even the most absurd 
>> desires of encapsulation
>> - It reminds me on operator definitions inside type declarations 
>> - No change for fileprivate needed (but actually, I think there is very 
>> little need to keep fileprivate)
>> 
>> I wish this would only be a joke, but writing the example, I actually 
>> started liking the concept (but I have a terrible headache right now which 
>> might affect my mind) — so either this receives some feedback, or I might 
>> start re-proposing this ;-)
>> 
>> - Tino
>> ___
>> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Tony Arnold via swift-evolution]

Hi Tino,

> On 8 Apr 2017, at 22:03, Tino Heth via swift-evolution 
>  wrote:
> 
> I wish this would only be a joke, but writing the example, I actually started 
> liking the concept (but I have a terrible headache right now which might 
> affect my mind) — so either this receives some feedback, or I might start 
> re-proposing this ;-)

I’m not sure that this solves anything meaningful (whether in relation to 
SE-0169 or more generally), does it? What advantage does this provide over just 
declaring the protocol conformance and those methods as a direct part of the 
parent type? This seems like it would just introduce more indentation, and more 
lines of code, for zero benefit.

cheers,


Tony



--
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Jonathan Hull via swift-evolution]

This struck me as a bit odd at first, but the more I think about it, the more I 
really like the ability to nest extensions/scopes.  The one issue I see is 
sticking that public extension inside a private one.  I think you would have to 
mark ‘secret: Int’ as private instead of the extension itself to allow the 
effect you are looking for...

What I ultimately want is the ability to declare storage in extensions in the 
same submodule. Combining that with fileprivate will allow the same tricks 
without the indentation (together in their own file).  This nesting will help 
in the mean-time (and would still be useful after for those who prefer to 
organize their code in fewer/longer files).  I think it could be helpful in 
other ways too...

Thanks,
Jon

> On Apr 8, 2017, at 5:03 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> Imho there is a simple solution to reach the goals of SE-0169 without 
> breaking compatibility:
> Just allow extensions inside type declarations.
> 
> class MyVC: UIViewController {
> private let numberOfSections = 0
> 
> extension: UITableViewDataSource {
> // Skipping the class and assume we want to extend the surrounding 
> type
> func numberOfSections(in tableView: UITableView) -> Int {
> return numberOfSections
> }
> 
> func tableView(_ tableView: UITableView, numberOfRowsInSection 
> section: Int) -> Int {
> return 0
> }
> }
> 
> private extension {
> // this would contain everything that shoudn't be visible for other 
> extensios
> 
> var secret: Int = 0
> 
> public extension MyFriendClass {
> // oh, well, I make an exception here for a trustworthy type
> func checkSecret(of controller: MyVC) -> Bool {
> return controller.secret > 0
> }
> }
> 
> private extension {
> // this is so secret, I'm not even allowed to copy it
> }
> }
> 
> public func myMethod() {
> print("This is just a boring method")
> }
> }
> 
> It has the downside of shifting code to the right (you could as well leave 
> those extension-blocks unindented), but lots of advantages:
> - No change for private needed
> - It can be nested as much as you like to satisfy even the most absurd 
> desires of encapsulation
> - It reminds me on operator definitions inside type declarations 
> - No change for fileprivate needed (but actually, I think there is very 
> little need to keep fileprivate)
> 
> I wish this would only be a joke, but writing the example, I actually started 
> liking the concept (but I have a terrible headache right now which might 
> affect my mind) — so either this receives some feedback, or I might start 
> re-proposing this ;-)
> 
> - Tino
> ___
> 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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Charlie Monroe via swift-evolution]

This seems like a nice compromise, though it introduces a "horizontal" issue of 
indentation. Not a huge issue IMHO, though I think some people may see it as a 
downside.

For me, it's +1, though.

> On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> Imho there is a simple solution to reach the goals of SE-0169 without 
> breaking compatibility:
> Just allow extensions inside type declarations.
> 
> class MyVC: UIViewController {
> private let numberOfSections = 0
> 
> extension: UITableViewDataSource {
> // Skipping the class and assume we want to extend the surrounding 
> type
> func numberOfSections(in tableView: UITableView) -> Int {
> return numberOfSections
> }
> 
> func tableView(_ tableView: UITableView, numberOfRowsInSection 
> section: Int) -> Int {
> return 0
> }
> }
> 
> private extension {
> // this would contain everything that shoudn't be visible for other 
> extensios
> 
> var secret: Int = 0
> 
> public extension MyFriendClass {
> // oh, well, I make an exception here for a trustworthy type
> func checkSecret(of controller: MyVC) -> Bool {
> return controller.secret > 0
> }
> }
> 
> private extension {
> // this is so secret, I'm not even allowed to copy it
> }
> }
> 
> public func myMethod() {
> print("This is just a boring method")
> }
> }
> 
> It has the downside of shifting code to the right (you could as well leave 
> those extension-blocks unindented), but lots of advantages:
> - No change for private needed
> - It can be nested as much as you like to satisfy even the most absurd 
> desires of encapsulation
> - It reminds me on operator definitions inside type declarations 
> - No change for fileprivate needed (but actually, I think there is very 
> little need to keep fileprivate)
> 
> I wish this would only be a joke, but writing the example, I actually started 
> liking the concept (but I have a terrible headache right now which might 
> affect my mind) — so either this receives some feedback, or I might start 
> re-proposing this ;-)
> 
> - Tino
> ___
> 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] Enhancing access levels without breaking changes

[Tino Heth via swift-evolution]

Imho there is a simple solution to reach the goals of SE-0169 without breaking 
compatibility:
Just allow extensions inside type declarations.

class MyVC: UIViewController {
private let numberOfSections = 0

extension: UITableViewDataSource {
// Skipping the class and assume we want to extend the surrounding type
func numberOfSections(in tableView: UITableView) -> Int {
return numberOfSections
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: 
Int) -> Int {
return 0
}
}

private extension {
// this would contain everything that shoudn't be visible for other 
extensios

var secret: Int = 0

public extension MyFriendClass {
// oh, well, I make an exception here for a trustworthy type
func checkSecret(of controller: MyVC) -> Bool {
return controller.secret > 0
}
}

private extension {
// this is so secret, I'm not even allowed to copy it
}
}

public func myMethod() {
print("This is just a boring method")
}
}

It has the downside of shifting code to the right (you could as well leave 
those extension-blocks unindented), but lots of advantages:
- No change for private needed
- It can be nested as much as you like to satisfy even the most absurd desires 
of encapsulation
- It reminds me on operator definitions inside type declarations 
- No change for fileprivate needed (but actually, I think there is very little 
need to keep fileprivate)

I wish this would only be a joke, but writing the example, I actually started 
liking the concept (but I have a terrible headache right now which might affect 
my mind) — so either this receives some feedback, or I might start re-proposing 
this ;-)

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