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 > > wrote: > >> On Apr 11, 2017, at 10:30 PM, David Hart >

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

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

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,

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,

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

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

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

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

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

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 >

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

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 >

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

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

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:

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

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 >> > wrote: >> >> On 11 Apr 2017, at 09:40, John McCall >

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

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

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 > > wrote: > >> I have not voted in favor or

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

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

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

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

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

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

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

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

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

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

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

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 >> > a écrit : >> >> >> >> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >>

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 > > wrote: > >> >>> On Apr 9, 2017, at 7:14 PM, Jonathan

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

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

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

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

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

[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