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

> On Apr 12, 2017, at 6:09 AM, Ricardo Parada wrote: > > > On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Apr 11, 2017, at 10:30 PM, David Hart > > wrote: To me, the reason for limiting it to a

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

...@nondot.org>> > Cc: swift-evolution <mailto:swift-evolution@swift.org>> > Subject: Re: [swift-evolution] Enhancing access levels without > breakingchanges > Message-ID: <mailto:dacd7de1-6bc6-457a-be4d-b074c7b39...@hartbit.com>> > Content-Type:

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

> 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

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

> 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 (f

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

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 pri

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

> On 12 Apr 2017, at 07:16, Chris Lattner wrote: > > 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

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

> 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

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

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 t

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

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 sam

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

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

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

SE-0169 is under active review, and is about expanding the meaning of scope to include extensions in the same file. The last day of the review period is today. What is this about yet another change? On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution < swift-evolution@swift.org> wrote: >

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

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

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

> 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

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

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

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

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 wro

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

> 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 >> mailto:swift-evolution@swif

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

> 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

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

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

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

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

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

> 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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Sent from my iPhone >>

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

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

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

> 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 > mailto:swift-evolution@swift.org>> wrote: > >> I have not voted in favor or against the proposal. I have been reading a lot >> of res

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

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

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

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 extension

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

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").

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

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

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

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

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

> 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+He

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

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

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

On Mon, Apr 10, 2017 at 8:26 AM Tino Heth via swift-evolution < swift-evolution@swift.org> 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 t

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

> On 10 Apr 2017, at 08:21, Jean-Daniel wrote: > > >> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> >> >> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >

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

> 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 > mailto:swift-evolution@swift.org>> wrote: > >> >>> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swif

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

> 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/sc

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

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

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

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

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

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

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

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 so

[swift-evolution] Enhancing access levels without breaking changes

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 wan