Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

> 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,

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

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,

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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

Re: [swift-evolution] private extension

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 {

[swift-evolution] private extension

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