Re: [swift-evolution] private extension

[Xiaodi Wu via swift-evolution]

Vladimir, please follow the link for the previous discussion. There are
several reasons outlined by core team members why they felt this was not a
bug, so it is definitely not the case that there are no opinions to that
effect. It was a very thorough conversation on the topic, and I’m not sure
what further statement you’d want from them.
On Thu, Aug 10, 2017 at 09:12 Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW, I can't agree that this particular subject leads to huge
> discussion/battle
> about all the access modifiers. It is just about 'private extension'
> inconsistency,
> not more. And it seems like there no(?) opinions that current situation
> with private
> extension has any sense. It really looks like a bug.
>
> So, I'd like to ask, if it is possible, some note about the subject from
> core team. I
> hope they can revisit their decision to not even discuss *this particular*
> confusing
> case with private extension.
>
> On 10.08.2017 16:28, Tino Heth via swift-evolution wrote:
> >
> >> I agree, but after having originally raised the issue, members of the
> core team
> >> clearly disagreed. Therefore, it's clear that this is going to have to
> go through
> >> Swift Evolution or not be changed at all. And I also agree with the
> notion that
> >> further discussions of access modifiers, which will most certainly lead
> to a rehash
> >> of the whole sordid past, is unhealthy.
> > I guess that is the price to pay for stability… I personally am quite
> sad that Swift
> > reached that phase already.
> > But who knows — maybe after some years of collecting legacy, this might
> be discussed
> > again in a cleanup release of Swift.
> >
> > Still, I think the current situation is a pity, as everyone seems to
> agree that we
> > ended up with a flawed solution for access control :-(
> >
> >
> > ___
> > 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] private extension

[Vladimir.S via swift-evolution]

FWIW, I can't agree that this particular subject leads to huge discussion/battle 
about all the access modifiers. It is just about 'private extension' inconsistency, 
not more. And it seems like there no(?) opinions that current situation with private 
extension has any sense. It really looks like a bug.


So, I'd like to ask, if it is possible, some note about the subject from core team. I 
hope they can revisit their decision to not even discuss *this particular* confusing 
case with private extension.


On 10.08.2017 16:28, Tino Heth via swift-evolution wrote:


I agree, but after having originally raised the issue, members of the core team 
clearly disagreed. Therefore, it's clear that this is going to have to go through 
Swift Evolution or not be changed at all. And I also agree with the notion that 
further discussions of access modifiers, which will most certainly lead to a rehash 
of the whole sordid past, is unhealthy.
I guess that is the price to pay for stability… I personally am quite sad that Swift 
reached that phase already.
But who knows — maybe after some years of collecting legacy, this might be discussed 
again in a cleanup release of Swift.


Still, I think the current situation is a pity, as everyone seems to agree that we 
ended up with a flawed solution for access control :-(



___
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] private extension

[Tino Heth via swift-evolution]

> I agree, but after having originally raised the issue, members of the core 
> team clearly disagreed. Therefore, it's clear that this is going to have to 
> go through Swift Evolution or not be changed at all. And I also agree with 
> the notion that further discussions of access modifiers, which will most 
> certainly lead to a rehash of the whole sordid past, is unhealthy.
I guess that is the price to pay for stability… I personally am quite sad that 
Swift reached that phase already.
But who knows — maybe after some years of collecting legacy, this might be 
discussed again in a cleanup release of Swift.

Still, I think the current situation is a pity, as everyone seems to agree that 
we ended up with a flawed solution for access control :-(___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private extension

[Xiaodi Wu via swift-evolution]

On Wed, Aug 9, 2017 at 5:52 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> I counter with the rationale for rejecting SE-0119
> ,
> namely:
>
> The review of "SE-0119: Remove access modifiers from extensions" ran from
>> July 12...19. The proposal has been *rejected*.
>>
>> The majority of the feedback on this proposal was opposed to it, because
>> it eliminated the useful ability to apply access control to a batch of
>> methods and properties.
>
>
> In other words, access modifiers are allowed on extensions for the express
> purpose of being applied to the members in that extension. The fact that in
> one of them currently does something *other* than what it says on the tin
> is therefore problematic.
>

I agree, but after having originally raised the issue, members of the core
team clearly disagreed. Therefore, it's clear that this is going to have to
go through Swift Evolution or not be changed at all. And I also agree with
the notion that further discussions of access modifiers, which will most
certainly lead to a rehash of the whole sordid past, is unhealthy.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] private extension

[Nevin Brackett-Rozinsky via swift-evolution]

I counter with the rationale for rejecting SE-0119
,
namely:

The review of "SE-0119: Remove access modifiers from extensions" ran from
> July 12...19. The proposal has been *rejected*.
>
> The majority of the feedback on this proposal was opposed to it, because
> it eliminated the useful ability to apply access control to a batch of
> methods and properties.


In other words, access modifiers are allowed on extensions for the express
purpose of being applied to the members in that extension. The fact that in
one of them currently does something *other* than what it says on the tin
is therefore problematic.

Nevin


On Wed, Aug 9, 2017 at 6:31 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170417/035885.html
>
>
> On Wed, Aug 9, 2017 at 17:05 David Hart  wrote:
>
>> Do you a have a link to that discussion?
>>
>>
>> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
>>
>> Agree, but again, I tried, and the answer was no, it’s not considered a
>> bug and cannot be fixed without independent discussion.
>> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>>
>>> The last thing I want is to launch into a new round of discussions. I am
>>> just hoping it can be considered as a straight bug that can be fixed
>>> without any discussion.
>>>
>>>
>>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>>
>>> I brought this up after SE-0169, but it was deemed to be a separate
>>> issue and any further consideration was declined. Let’s not initiate
>>> another round of access control discussions.
>>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Actually, I think this is this way only as a relic from the original
 private/fileprivate proposal. Swift 3’s private has no meaning as an
 extension modifier, so it was made to alias to fileprivate. But
 since SE-0169 modified private’s meaning so that it would make sense
 as an extension modifier, I think we should fix this.

 On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
 swift-evolution@swift.org> wrote:

 That behaviour was never explicitly mentioned in SE-0169 but I agree
 its confusing. But I’m also fairly sure the only window to do anything
 about it is Swift 4. Everybody is really worn down by those access level
 discussions.

 For illustration, Vladimir is confused that:

 private extension Foo {
 func foo() {}
 }

 is equivalent to:

 fileprivate extension Foo {
 func foo() {}
 }

 making it accessible to another type in the same file:

 struct Bar {
 func bar(foo: Foo) {
 foo.foo()
 }
 }

 Aren't access levels on extensions supposed to define the default
 access level of the members of the extension?Is this a bug then?

 On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
 swift-evolution@swift.org> wrote:

 Could someone remind please, was it decided to stick with 'private
 extension' means actually fileprivate access level for members declared in
 such extension or this could be discussed for Swift5?

 Currently, when private members are visible in type/extensions of that
 type in the same file, IMO there is no sense to treat 'private extension'
 as 'fileprivate extension', it is reasonable to group some private members
 of type into extension without making them fileprivate, and such members
 can be used from the type/other extensions.

 And also this is a huge inconsistency in my opinion: all other access
 modifiers 'work' as expected for extensions, but only 'private extension'
 means not what written, very surprising for one who don't expect this.
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution


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


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

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

Re: [swift-evolution] private extension

[Nevin Brackett-Rozinsky via swift-evolution]

I agree this should be considered a simple bug. Have you filed a bug report?

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

Re: [swift-evolution] private extension

[Xiaodi Wu via swift-evolution]

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html

On Wed, Aug 9, 2017 at 17:05 David Hart  wrote:

> Do you a have a link to that discussion?
>
>
> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
>
> Agree, but again, I tried, and the answer was no, it’s not considered a
> bug and cannot be fixed without independent discussion.
> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>
>> The last thing I want is to launch into a new round of discussions. I am
>> just hoping it can be considered as a straight bug that can be fixed
>> without any discussion.
>>
>>
>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>
>> I brought this up after SE-0169, but it was deemed to be a separate issue
>> and any further consideration was declined. Let’s not initiate another
>> round of access control discussions.
>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Actually, I think this is this way only as a relic from the original
>>> private/fileprivate proposal. Swift 3’s private has no meaning as an
>>> extension modifier, so it was made to alias to fileprivate. But
>>> since SE-0169 modified private’s meaning so that it would make sense as
>>> an extension modifier, I think we should fix this.
>>>
>>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> That behaviour was never explicitly mentioned in SE-0169 but I agree its
>>> confusing. But I’m also fairly sure the only window to do anything about it
>>> is Swift 4. Everybody is really worn down by those access level discussions.
>>>
>>> For illustration, Vladimir is confused that:
>>>
>>> private extension Foo {
>>> func foo() {}
>>> }
>>>
>>> is equivalent to:
>>>
>>> fileprivate extension Foo {
>>> func foo() {}
>>> }
>>>
>>> making it accessible to another type in the same file:
>>>
>>> struct Bar {
>>> func bar(foo: Foo) {
>>> foo.foo()
>>> }
>>> }
>>>
>>> Aren't access levels on extensions supposed to define the default access
>>> level of the members of the extension?Is this a bug then?
>>>
>>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Could someone remind please, was it decided to stick with 'private
>>> extension' means actually fileprivate access level for members declared in
>>> such extension or this could be discussed for Swift5?
>>>
>>> Currently, when private members are visible in type/extensions of that
>>> type in the same file, IMO there is no sense to treat 'private extension'
>>> as 'fileprivate extension', it is reasonable to group some private members
>>> of type into extension without making them fileprivate, and such members
>>> can be used from the type/other extensions.
>>>
>>> And also this is a huge inconsistency in my opinion: all other access
>>> modifiers 'work' as expected for extensions, but only 'private extension'
>>> means not what written, very surprising for one who don't expect this.
>>> ___
>>> 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] private extension

[David Hart via swift-evolution]

Do you a have a link to that discussion?

> On 10 Aug 2017, at 00:04, Xiaodi Wu  wrote:
> 
> Agree, but again, I tried, and the answer was no, it’s not considered a bug 
> and cannot be fixed without independent discussion.
>> On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:
>> The last thing I want is to launch into a new round of discussions. I am 
>> just hoping it can be considered as a straight bug that can be fixed without 
>> any discussion.
>> 
>> 
>>> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>>> 
>>> I brought this up after SE-0169, but it was deemed to be a separate issue 
>>> and any further consideration was declined. Let’s not initiate another 
>>> round of access control discussions.
 On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution 
  wrote:
 Actually, I think this is this way only as a relic from the original 
 private/fileprivate proposal. Swift 3’s private has no meaning as an 
 extension modifier, so it was made to alias to fileprivate. But since 
 SE-0169 modified private’s meaning so that it would make sense as an 
 extension modifier, I think we should fix this.
 
> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>  wrote:
> 
> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
> confusing. But I’m also fairly sure the only window to do anything about 
> it is Swift 4. Everybody is really worn down by those access level 
> discussions.
> 
> For illustration, Vladimir is confused that:
> 
> private extension Foo {
> func foo() {}
> }
> 
> is equivalent to:
> 
> fileprivate extension Foo {
> func foo() {}
> }
> 
> making it accessible to another type in the same file:
> 
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
> 
> Aren't access levels on extensions supposed to define the default access 
> level of the members of the extension?Is this a bug then?
> 
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> Could someone remind please, was it decided to stick with 'private 
>> extension' means actually fileprivate access level for members declared 
>> in such extension or this could be discussed for Swift5?
>> 
>> Currently, when private members are visible in type/extensions of that 
>> type in the same file, IMO there is no sense to treat 'private 
>> extension' as 'fileprivate extension', it is reasonable to group some 
>> private members of type into extension without making them fileprivate, 
>> and such members can be used from the type/other extensions.
>> 
>> And also this is a huge inconsistency in my opinion: all other access 
>> modifiers 'work' as expected for extensions, but only 'private 
>> extension' means not what written, very surprising for one who don't 
>> expect this.
>> ___
>> 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] private extension

[Xiaodi Wu via swift-evolution]

Agree, but again, I tried, and the answer was no, it’s not considered a bug
and cannot be fixed without independent discussion.
On Wed, Aug 9, 2017 at 16:51 David Hart  wrote:

> The last thing I want is to launch into a new round of discussions. I am
> just hoping it can be considered as a straight bug that can be fixed
> without any discussion.
>
>
> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
>
> I brought this up after SE-0169, but it was deemed to be a separate issue
> and any further consideration was declined. Let’s not initiate another
> round of access control discussions.
> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Actually, I think this is this way only as a relic from the original
>> private/fileprivate proposal. Swift 3’s private has no meaning as an
>> extension modifier, so it was made to alias to fileprivate. But
>> since SE-0169 modified private’s meaning so that it would make sense as
>> an extension modifier, I think we should fix this.
>>
>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> That behaviour was never explicitly mentioned in SE-0169 but I agree its
>> confusing. But I’m also fairly sure the only window to do anything about it
>> is Swift 4. Everybody is really worn down by those access level discussions.
>>
>> For illustration, Vladimir is confused that:
>>
>> private extension Foo {
>> func foo() {}
>> }
>>
>> is equivalent to:
>>
>> fileprivate extension Foo {
>> func foo() {}
>> }
>>
>> making it accessible to another type in the same file:
>>
>> struct Bar {
>> func bar(foo: Foo) {
>> foo.foo()
>> }
>> }
>>
>> Aren't access levels on extensions supposed to define the default access
>> level of the members of the extension?Is this a bug then?
>>
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Could someone remind please, was it decided to stick with 'private
>> extension' means actually fileprivate access level for members declared in
>> such extension or this could be discussed for Swift5?
>>
>> Currently, when private members are visible in type/extensions of that
>> type in the same file, IMO there is no sense to treat 'private extension'
>> as 'fileprivate extension', it is reasonable to group some private members
>> of type into extension without making them fileprivate, and such members
>> can be used from the type/other extensions.
>>
>> And also this is a huge inconsistency in my opinion: all other access
>> modifiers 'work' as expected for extensions, but only 'private extension'
>> means not what written, very surprising for one who don't expect this.
>> ___
>> 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] private extension

[David Hart via swift-evolution]

The last thing I want is to launch into a new round of discussions. I am just 
hoping it can be considered as a straight bug that can be fixed without any 
discussion.

> On 9 Aug 2017, at 23:47, Xiaodi Wu  wrote:
> 
> I brought this up after SE-0169, but it was deemed to be a separate issue and 
> any further consideration was declined. Let’s not initiate another round of 
> access control discussions.
>> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution 
>>  wrote:
>> Actually, I think this is this way only as a relic from the original 
>> private/fileprivate proposal. Swift 3’s private has no meaning as an 
>> extension modifier, so it was made to alias to fileprivate. But since 
>> SE-0169 modified private’s meaning so that it would make sense as an 
>> extension modifier, I think we should fix this.
>> 
>>> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
>>> confusing. But I’m also fairly sure the only window to do anything about it 
>>> is Swift 4. Everybody is really worn down by those access level discussions.
>>> 
>>> For illustration, Vladimir is confused that:
>>> 
>>> private extension Foo {
>>> func foo() {}
>>> }
>>> 
>>> is equivalent to:
>>> 
>>> fileprivate extension Foo {
>>> func foo() {}
>>> }
>>> 
>>> making it accessible to another type in the same file:
>>> 
>>> struct Bar {
>>> func bar(foo: Foo) {
>>> foo.foo()
>>> }
>>> }
>>> 
>>> Aren't access levels on extensions supposed to define the default access 
>>> level of the members of the extension?Is this a bug then?
>>> 
 On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
  wrote:
 
 Could someone remind please, was it decided to stick with 'private 
 extension' means actually fileprivate access level for members declared in 
 such extension or this could be discussed for Swift5?
 
 Currently, when private members are visible in type/extensions of that 
 type in the same file, IMO there is no sense to treat 'private extension' 
 as 'fileprivate extension', it is reasonable to group some private members 
 of type into extension without making them fileprivate, and such members 
 can be used from the type/other extensions.
 
 And also this is a huge inconsistency in my opinion: all other access 
 modifiers 'work' as expected for extensions, but only 'private extension' 
 means not what written, very surprising for one who don't expect this.
 ___
 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] private extension

[Xiaodi Wu via swift-evolution]

I brought this up after SE-0169, but it was deemed to be a separate issue
and any further consideration was declined. Let’s not initiate another
round of access control discussions.
On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Actually, I think this is this way only as a relic from the original
> private/fileprivate proposal. Swift 3’s private has no meaning as an
> extension modifier, so it was made to alias to fileprivate. But
> since SE-0169 modified private’s meaning so that it would make sense as
> an extension modifier, I think we should fix this.
>
> On 9 Aug 2017, at 23:22, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That behaviour was never explicitly mentioned in SE-0169 but I agree its
> confusing. But I’m also fairly sure the only window to do anything about it
> is Swift 4. Everybody is really worn down by those access level discussions.
>
> For illustration, Vladimir is confused that:
>
> private extension Foo {
> func foo() {}
> }
>
> is equivalent to:
>
> fileprivate extension Foo {
> func foo() {}
> }
>
> making it accessible to another type in the same file:
>
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
>
> Aren't access levels on extensions supposed to define the default access
> level of the members of the extension?Is this a bug then?
>
> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Could someone remind please, was it decided to stick with 'private
> extension' means actually fileprivate access level for members declared in
> such extension or this could be discussed for Swift5?
>
> Currently, when private members are visible in type/extensions of that
> type in the same file, IMO there is no sense to treat 'private extension'
> as 'fileprivate extension', it is reasonable to group some private members
> of type into extension without making them fileprivate, and such members
> can be used from the type/other extensions.
>
> And also this is a huge inconsistency in my opinion: all other access
> modifiers 'work' as expected for extensions, but only 'private extension'
> means not what written, very surprising for one who don't expect this.
> ___
> 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] private extension

[David Hart via swift-evolution]

Actually, I think this is this way only as a relic from the original 
private/fileprivate proposal. Swift 3’s private has no meaning as an extension 
modifier, so it was made to alias to fileprivate. But since SE-0169 modified 
private’s meaning so that it would make sense as an extension modifier, I think 
we should fix this.

> On 9 Aug 2017, at 23:22, David Hart via swift-evolution 
>  wrote:
> 
> That behaviour was never explicitly mentioned in SE-0169 but I agree its 
> confusing. But I’m also fairly sure the only window to do anything about it 
> is Swift 4. Everybody is really worn down by those access level discussions.
> 
> For illustration, Vladimir is confused that:
> 
> private extension Foo {
> func foo() {}
> }
> 
> is equivalent to:
> 
> fileprivate extension Foo {
> func foo() {}
> }
> 
> making it accessible to another type in the same file:
> 
> struct Bar {
> func bar(foo: Foo) {
> foo.foo()
> }
> }
> 
> Aren't access levels on extensions supposed to define the default access 
> level of the members of the extension?Is this a bug then?
> 
>> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>> > wrote:
>> 
>> Could someone remind please, was it decided to stick with 'private 
>> extension' means actually fileprivate access level for members declared in 
>> such extension or this could be discussed for Swift5?
>> 
>> Currently, when private members are visible in type/extensions of that type 
>> in the same file, IMO there is no sense to treat 'private extension' as 
>> 'fileprivate extension', it is reasonable to group some private members of 
>> type into extension without making them fileprivate, and such members can be 
>> used from the type/other extensions.
>> 
>> And also this is a huge inconsistency in my opinion: all other access 
>> modifiers 'work' as expected for extensions, but only 'private extension' 
>> means not what written, very surprising for one who don't expect this.
>> ___
>> 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] private extension

[David Hart via swift-evolution]

That behaviour was never explicitly mentioned in SE-0169 but I agree its 
confusing. But I’m also fairly sure the only window to do anything about it is 
Swift 4. Everybody is really worn down by those access level discussions.

For illustration, Vladimir is confused that:

private extension Foo {
func foo() {}
}

is equivalent to:

fileprivate extension Foo {
func foo() {}
}

making it accessible to another type in the same file:

struct Bar {
func bar(foo: Foo) {
foo.foo()
}
}

Aren't access levels on extensions supposed to define the default access level 
of the members of the extension?Is this a bug then?

> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution 
>  wrote:
> 
> Could someone remind please, was it decided to stick with 'private extension' 
> means actually fileprivate access level for members declared in such 
> extension or this could be discussed for Swift5?
> 
> Currently, when private members are visible in type/extensions of that type 
> in the same file, IMO there is no sense to treat 'private extension' as 
> 'fileprivate extension', it is reasonable to group some private members of 
> type into extension without making them fileprivate, and such members can be 
> used from the type/other extensions.
> 
> And also this is a huge inconsistency in my opinion: all other access 
> modifiers 'work' as expected for extensions, but only 'private extension' 
> means not what written, very surprising for one who don't expect this.
> ___
> 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