[swift-evolution] SE-0157: Support recursive constraints on associated types

[John McCall via swift-evolution]

Proposal link:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md
 


Hello, Swift community.

The review of "SE-0157: Support recursive constraints on associated types" ran 
from Feburary 28th through March 8th, 2017.  The feedback on the proposal was 
unfailingly positive.  Accordingly, the proposal has been accepted without 
further modification.

As always, thank you very much for taking the time to weigh in on proposals you 
care about.

Sincerely,
John McCall,
Review Manager.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
>
> The bug *does not affect what people use private for,* and so it *does not
> affect anything in real-world use.* It’s less “the Finder makes your files
> disappear on a regular basis” and more “if you give a file a name with a
> very specific sequence of Plane 2 Unicode characters, and then set the
> ‘Stationery' bit in the Finder flags, the icon doesn’t draw correctly.”
> It’s a bug, and it should be fixed, but it’s not even close to being a
> show-stopper.
>

This, 100%.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu > > wrote:
> 
>> 
>> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka >> > wrote:
>>> 
 On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > wrote:
 
 On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  > wrote:
 
> 
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> So, if four/five access modifiers are too many, which one is carrying 
>> the least weight? Which one could be removed to simplify the scheme 
>> while maintaining the most expressiveness? Which one doesn't fulfill 
>> even its own stated goals? Well, one of the key goals of `private` was 
>> to allow members to be encapsulated within an extension, hidden even 
>> from the type being extended (and vice versa for members defined in the 
>> type). It says so in the first sentence of SE-0025. As seen above in my 
>> discussion with Charles Srstka, even supporters of `private` disagree 
>> with that motivation to begin with. The kicker is, _it also doesn't 
>> work_. Try, for instance:
>> 
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>> 
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>> 
>> The code above should compile and does not. If I understood correctly 
>> the explanation from a core team member on this list, it's unclear if it 
>> can be made to work without changing how mangling works, which I believe 
>> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
>> `private` disagree on one of two key goals stated for new `private`; (b) 
>> that goal was never accomplished, and making it work is not trivial; (c) 
>> no one even complained about it, suggesting that it was a low-yield goal 
>> in the first place.
> 
> Multiple people have already brought up cases in which they are using 
> ‘private’. The repeated mention of another, unrelated use case that was 
> mentioned in the SE-0025 proposal does not invalidate the real-world use 
> cases which have been presented. In fact, it rather makes it appear as if 
> the motivation to remove ‘private’ is based on a strange invocation of 
> the appeal-to-authority fallacy, rather than an actual improvement to the 
> language.
> 
> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
> implemented. And as I said above, IIUC, it cannot be fully implemented 
> without ripping out a lot of mangling code that is unlikely to be ripped 
> out before Swift 4. _And there is no evidence that anyone cares about 
> this flaw; in fact, you are saying as much, that you do not care at all!_ 
> If this is not sufficient indication that the design of SE-0025 does not 
> fit with the overall direction of Swift, what would be?
 
 Because there are other uses cases for ‘private', *not* involving 
 extensions, which I *do* care about. The fact that part of the proposal 
 was badly written (and really, that’s all this is
 
 Huh? The code above *should compile*--that is a primary aim for SE-0025. 
 It does not compile and there is not a timeline (afaict) for its 
 compiling. It does not bother you that the 25th proposal considered in the 
 Swift evolution process, already once revised, is not fully implemented 
 and may never be?
>>> 
>>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>>> to throw out the baby with the bathwater, no.
>>> 
>>> You're not hearing the argument. No one "accidentally" included this design 
>>> as part of SE-0025; it's sentence number one.
>> 
>> Or not. Here’s the actual text of the introductory paragraph:
>> 
>> "Scoped access level allows hiding implementation details of a class or a 
>> class extension at the class/extension level, instead of a file. It is a 
>> concise expression of the intent that a particular part of a class 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
>>
>>
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>>
>>>
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>>
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:


 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  wrote:

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> So, if four/five access modifiers are too many, which one is carrying
> the least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own
> stated goals? Well, one of the key goals of `private` was to allow members
> to be encapsulated within an extension, hidden even from the type being
> extended (and vice versa for members defined in the type). It says so in
> the first sentence of SE-0025. As seen above in my discussion with Charles
> Srstka, even supporters of `private` disagree with that motivation to 
> begin
> with. The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly
> the explanation from a core team member on this list, it's unclear if it
> can be made to work without changing how mangling works, which I believe
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new
> `private` disagree on one of two key goals stated for new `private`; (b)
> that goal was never accomplished, and making it work is not trivial; (c) 
> no
> one even complained about it, suggesting that it was a low-yield goal in
> the first place.
>
>
> Multiple people have already brought up cases in which they are using
> ‘private’. The repeated mention of another, unrelated use case that was
> mentioned in the SE-0025 proposal does not invalidate the real-world use
> cases which have been presented. In fact, it rather makes it appear as if
> the motivation to remove ‘private’ is based on a strange invocation of the
> appeal-to-authority fallacy, rather than an actual improvement to the
> language.
>

 I'm not sure how to respond to this. SE-0025, as designed, is not fully
 implemented. And as I said above, IIUC, it cannot be fully implemented
 without ripping out a lot of mangling code that is unlikely to be ripped
 out before Swift 4. _And there is no evidence that anyone cares about this
 flaw; in fact, you are saying as much, that you do not care at all!_ If
 this is not sufficient indication that the design of SE-0025 does not fit
 with the overall direction of Swift, what would be?


 Because there are other uses cases for ‘private', *not* involving
 extensions, which I *do* care about. The fact that part of the proposal was
 badly written (and really, that’s all this is

>>>
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>>> It does not compile and there is not a timeline (afaict) for its compiling.
>>> It does not bother you that the 25th proposal considered in the Swift
>>> evolution process, already once revised, is not fully implemented and may
>>> never be?
>>>
>>>
>>> Someone finding a bug/oversight in the compiler behavior does not compel
>>> me to throw out the baby with the bathwater, no.
>>>
>>
>> You're not hearing the argument. No one "accidentally" included this
>> design as part of SE-0025; it's sentence number one.
>>
>>
>> Or not. Here’s the actual text of the introductory paragraph:
>>
>> "Scoped access level allows hiding implementation details of a class or a
>> class extension at the class/extension level, instead of a file. It is a
>> concise expression of the intent that a particular part of a class or
>> extension definition is there only to implement a public API for other
>> classes or extensions and must not be used directly anywhere outside of the
>> scope of the class or the extension.”
>>
>> So here we have “class or extension”, or some variant thereof, five
>> separate times. It honestly reads like it originally just said “class”, and
>> the author systematically went through it and added “or extension” to each
>> of them to make sure his/her bases were 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>> 
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > wrote:
>>> 
 
 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own stated goals? Well, one of the key goals of `private` was to allow 
> members to be encapsulated within an extension, hidden even from the type 
> being extended (and vice versa for members defined in the type). It says 
> so in the first sentence of SE-0025. As seen above in my discussion with 
> Charles Srstka, even supporters of `private` disagree with that 
> motivation to begin with. The kicker is, _it also doesn't work_. Try, for 
> instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can 
> be made to work without changing how mangling works, which I believe 
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
> `private` disagree on one of two key goals stated for new `private`; (b) 
> that goal was never accomplished, and making it work is not trivial; (c) 
> no one even complained about it, suggesting that it was a low-yield goal 
> in the first place.
 
 Multiple people have already brought up cases in which they are using 
 ‘private’. The repeated mention of another, unrelated use case that was 
 mentioned in the SE-0025 proposal does not invalidate the real-world use 
 cases which have been presented. In fact, it rather makes it appear as if 
 the motivation to remove ‘private’ is based on a strange invocation of the 
 appeal-to-authority fallacy, rather than an actual improvement to the 
 language.
 
 I'm not sure how to respond to this. SE-0025, as designed, is not fully 
 implemented. And as I said above, IIUC, it cannot be fully implemented 
 without ripping out a lot of mangling code that is unlikely to be ripped 
 out before Swift 4. _And there is no evidence that anyone cares about this 
 flaw; in fact, you are saying as much, that you do not care at all!_ If 
 this is not sufficient indication that the design of SE-0025 does not fit 
 with the overall direction of Swift, what would be?
>>> 
>>> Because there are other uses cases for ‘private', *not* involving 
>>> extensions, which I *do* care about. The fact that part of the proposal was 
>>> badly written (and really, that’s all this is
>>> 
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>>> does not compile and there is not a timeline (afaict) for its compiling. It 
>>> does not bother you that the 25th proposal considered in the Swift 
>>> evolution process, already once revised, is not fully implemented and may 
>>> never be?
>> 
>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>> to throw out the baby with the bathwater, no.
>> 
>> You're not hearing the argument. No one "accidentally" included this design 
>> as part of SE-0025; it's sentence number one.
> 
> Or not. Here’s the actual text of the introductory paragraph:
> 
> "Scoped access level allows hiding implementation details of a class or a 
> class extension at the class/extension level, instead of a file. It is a 
> concise expression of the intent that a particular part of a class or 
> extension definition is there only to implement a public API for other 
> classes or extensions and must not be used directly anywhere outside of the 
> scope of the class or the extension.”
> 
> So here we have “class or extension”, or some variant thereof, five separate 
> times. It honestly reads like it 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson 
wrote:

>
> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu  wrote:
>
> On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson 
> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
>> wrote:
>>
>>> I am confused by this response. An argument in _support_ of new
>>> `private` was that it is more in line with expectations of users coming
>>> from other languages. In other some cases, such an argument might have its
>>> place. However, as others have pointed out on this list, those other
>>> languages don't have facilities like Swift's extensions, and therefore it
>>> was not a very strong argument for new `private` to say that it better
>>> aligns with user expectations coming from other languages.
>>>
>>> The underlying issue here (which I have now identified, thanks!) is what
>>> motivates the use of extensions.  That question predates proposals, but the
>>> Swift book provides the following motivation, which I have numbered for
>>> ease of reference:
>>>
>>> 1. Extensions add new functionality to an existing class, structure,
>>> enumeration, or protocol type.
>>>
>>> 2. This includes the ability to extend types for which you do not have
>>> access to the original source code (known as retroactive modeling).
>>>
>>> 3. Extensions are similar to categories in Objective-C.
>>>
>>> It seems to me this motivation contemplates use “at some distance”, that
>>> is we intend to create some semantically meaningful separation between the
>>> declaration and the extension(s).  If we did not we could use MARK or some
>>> other comment-based scheme to organize our class.
>>>
>>> 2 is explicitly at great distance, so we know the distance motivation is
>>> well within scope.  1 refers to “an existing” type which implies a certain
>>> level of functionality in the unextended type, and not merely a partial
>>> implementation in the unextended type.  The record on 3 is more mixed (ObjC
>>> programmers do occasionally use categories “closely-held” to group a few
>>> methods together).  However ObjC also has the “distance” tradition:
>>> categories cannot introduce new storage even when this is technically
>>> trivial (within the same compilation unit for example), and this tradition
>>> was continued under Swift with the new ABI.
>>>
>>> What I am suggesting is that the primary design purpose of an extension
>>> is to create semantic distance between a declaration and the functionality
>>> being added.
>>>
>>
>> I'm not sure it is necessary for extensions to have a "primary design
>> purpose." They serve many purposes. One use I have for them is as follows:
>>
>> ```
>> struct A {
>>   // Stuff here constitutes the "raison d'etre" for A.
>> }
>>
>> extension A : B {
>>   // In the course of implementing `A`, I have discovered that
>>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>>   // fulfills most of them already.
>>   //
>>   // So, I conform to B, as in so doing there are some practical
>>   // advantages, such as gaining some default implementations.
>>   //
>>   // But, to conform, I may need to implement some methods
>>   // not really essential for a functional `A`, but required nonetheless
>>   // to conform to `B`.
>>   //
>>   // I implement them here in an extension; in so doing, I express
>>   // the idea that I have, after implementing `A`, discovered its
>>   // conformance to `B`, and I am here supplying the remaining
>>   // implementations necessary for that conformance.
>>   //
>>   // That is, if `B` did not exist, neither would these functions here.
>>   // But there may be some requirements of `B` that would be
>>   // implemented in `A` whether or not `B` exists.
>>   // Those are implemented above, in `struct A { ... }`.
>> }
>> ```
>>
>> I find this to be an eloquent way to separate concerns. It is a common
>> pattern encouraged by code I admire written by others more skilled than me
>> in Swift.
>>
>> A mechanism to hide variables from extensions is something that
>>> *furthers* this design goal of extensions, rather than contradicts it.
>>>
>>
>> This, I suppose, is an argument for you to take up with Charles.
>>
>>
>>> I understand that some people use extensions as sort of an imitation
>>> “partial class” but they simply aren’t (no storage) and we should introduce
>>> a new feature if we want to have them.
>>>
>>> A core team member (I'm blanking on who) has pointed out that, in the
>>> end, the only necessary access modifiers are public and not public (spelled
>>> "internal" in Swift).
>>>
>>>
>>> It is not clear to me how this squares with the decision in SE-0025 that
>>> other access modifiers were necessary.  Can you clarify?
>>>
>>
>> Why do you think SE-0025 decided that other access modifiers are
>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
>  wrote:
>
>>
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>>
>>>
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:


 So, if four/five access modifiers are too many, which one is carrying
 the least weight? Which one could be removed to simplify the scheme while
 maintaining the most expressiveness? Which one doesn't fulfill even its own
 stated goals? Well, one of the key goals of `private` was to allow members
 to be encapsulated within an extension, hidden even from the type being
 extended (and vice versa for members defined in the type). It says so in
 the first sentence of SE-0025. As seen above in my discussion with Charles
 Srstka, even supporters of `private` disagree with that motivation to begin
 with. The kicker is, _it also doesn't work_. Try, for instance:

 ```
 struct Foo {
   private var bar: Int { return 42 }
 }

 extension Foo {
   private var bar: Int { return 43 }
 }
 ```

 The code above should compile and does not. If I understood correctly
 the explanation from a core team member on this list, it's unclear if it
 can be made to work without changing how mangling works, which I believe
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new
 `private` disagree on one of two key goals stated for new `private`; (b)
 that goal was never accomplished, and making it work is not trivial; (c) no
 one even complained about it, suggesting that it was a low-yield goal in
 the first place.


 Multiple people have already brought up cases in which they are using
 ‘private’. The repeated mention of another, unrelated use case that was
 mentioned in the SE-0025 proposal does not invalidate the real-world use
 cases which have been presented. In fact, it rather makes it appear as if
 the motivation to remove ‘private’ is based on a strange invocation of the
 appeal-to-authority fallacy, rather than an actual improvement to the
 language.

>>>
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>>> implemented. And as I said above, IIUC, it cannot be fully implemented
>>> without ripping out a lot of mangling code that is unlikely to be ripped
>>> out before Swift 4. _And there is no evidence that anyone cares about this
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>>> this is not sufficient indication that the design of SE-0025 does not fit
>>> with the overall direction of Swift, what would be?
>>>
>>>
>>> Because there are other uses cases for ‘private', *not* involving
>>> extensions, which I *do* care about. The fact that part of the proposal was
>>> badly written (and really, that’s all this is
>>>
>>
>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>> It does not compile and there is not a timeline (afaict) for its compiling.
>> It does not bother you that the 25th proposal considered in the Swift
>> evolution process, already once revised, is not fully implemented and may
>> never be?
>>
>>
>> Someone finding a bug/oversight in the compiler behavior does not compel
>> me to throw out the baby with the bathwater, no.
>>
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one.
>
>
> Or not. Here’s the actual text of the introductory paragraph:
>
> "Scoped access level allows hiding implementation details of a class or a
> class extension at the class/extension level, instead of a file. It is a
> concise expression of the intent that a particular part of a class or
> extension definition is there only to implement a public API for other
> classes or extensions and must not be used directly anywhere outside of the
> scope of the class or the extension.”
>
> So here we have “class or extension”, or some variant thereof, five
> separate times. It honestly reads like it originally just said “class”, and
> the author systematically went through it and added “or extension” to each
> of them to make sure his/her bases were covered.
>

The meaning of that sentence is made quite clear by the example in code
given in that proposal:

```

class A {
   private var counter = 0

   // public API that hides the internal state   func incrementCount()
{ ++counter }

   // hidden API, not visible outside of this 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 10:02 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson  > wrote:
> 
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>> 
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > wrote:
>>> 
 
 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own stated goals? Well, one of the key goals of `private` was to allow 
> members to be encapsulated within an extension, hidden even from the type 
> being extended (and vice versa for members defined in the type). It says 
> so in the first sentence of SE-0025. As seen above in my discussion with 
> Charles Srstka, even supporters of `private` disagree with that 
> motivation to begin with. The kicker is, _it also doesn't work_. Try, for 
> instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can 
> be made to work without changing how mangling works, which I believe 
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
> `private` disagree on one of two key goals stated for new `private`; (b) 
> that goal was never accomplished, and making it work is not trivial; (c) 
> no one even complained about it, suggesting that it was a low-yield goal 
> in the first place.
 
 Multiple people have already brought up cases in which they are using 
 ‘private’. The repeated mention of another, unrelated use case that was 
 mentioned in the SE-0025 proposal does not invalidate the real-world use 
 cases which have been presented. In fact, it rather makes it appear as if 
 the motivation to remove ‘private’ is based on a strange invocation of the 
 appeal-to-authority fallacy, rather than an actual improvement to the 
 language.
 
 I'm not sure how to respond to this. SE-0025, as designed, is not fully 
 implemented. And as I said above, IIUC, it cannot be fully implemented 
 without ripping out a lot of mangling code that is unlikely to be ripped 
 out before Swift 4. _And there is no evidence that anyone cares about this 
 flaw; in fact, you are saying as much, that you do not care at all!_ If 
 this is not sufficient indication that the design of SE-0025 does not fit 
 with the overall direction of Swift, what would be?
>>> 
>>> Because there are other uses cases for ‘private', *not* involving 
>>> extensions, which I *do* care about. The fact that part of the proposal was 
>>> badly written (and really, that’s all this is
>>> 
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>>> does not compile and there is not a timeline (afaict) for its compiling. It 
>>> does not bother you that the 25th proposal considered in the Swift 
>>> evolution process, already once revised, is not fully implemented and may 
>>> never be?
>> 
>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>> to throw out the baby with the bathwater, no.
>> 
>> You're not hearing the argument. No one "accidentally" included this design 
>> as part of SE-0025; it's sentence number one. And no one just "forgot" to 
>> make the code above work; it simply can't be accommodated by the current 
>> mangling scheme. And--what's more--_no one seems to be bothered by it_. If 
>> the first sentence of a proposal can't be implemented, and no one cares (!), 
>> is the proposal fundamentally flawed or is it just some bug?
> 
> The reason nobody cares much is because this is a degenerate case and is not 
> actually how people want to use the feature.  You don’t see people writing 
> identically named fileprivate methods in extensions of a type in different 
> files 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson 
wrote:

>
> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
> wrote:
>
>>
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>>
>>>
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:


 So, if four/five access modifiers are too many, which one is carrying
 the least weight? Which one could be removed to simplify the scheme while
 maintaining the most expressiveness? Which one doesn't fulfill even its own
 stated goals? Well, one of the key goals of `private` was to allow members
 to be encapsulated within an extension, hidden even from the type being
 extended (and vice versa for members defined in the type). It says so in
 the first sentence of SE-0025. As seen above in my discussion with Charles
 Srstka, even supporters of `private` disagree with that motivation to begin
 with. The kicker is, _it also doesn't work_. Try, for instance:

 ```
 struct Foo {
   private var bar: Int { return 42 }
 }

 extension Foo {
   private var bar: Int { return 43 }
 }
 ```

 The code above should compile and does not. If I understood correctly
 the explanation from a core team member on this list, it's unclear if it
 can be made to work without changing how mangling works, which I believe
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new
 `private` disagree on one of two key goals stated for new `private`; (b)
 that goal was never accomplished, and making it work is not trivial; (c) no
 one even complained about it, suggesting that it was a low-yield goal in
 the first place.


 Multiple people have already brought up cases in which they are using
 ‘private’. The repeated mention of another, unrelated use case that was
 mentioned in the SE-0025 proposal does not invalidate the real-world use
 cases which have been presented. In fact, it rather makes it appear as if
 the motivation to remove ‘private’ is based on a strange invocation of the
 appeal-to-authority fallacy, rather than an actual improvement to the
 language.

>>>
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>>> implemented. And as I said above, IIUC, it cannot be fully implemented
>>> without ripping out a lot of mangling code that is unlikely to be ripped
>>> out before Swift 4. _And there is no evidence that anyone cares about this
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>>> this is not sufficient indication that the design of SE-0025 does not fit
>>> with the overall direction of Swift, what would be?
>>>
>>>
>>> Because there are other uses cases for ‘private', *not* involving
>>> extensions, which I *do* care about. The fact that part of the proposal was
>>> badly written (and really, that’s all this is
>>>
>>
>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>> It does not compile and there is not a timeline (afaict) for its compiling.
>> It does not bother you that the 25th proposal considered in the Swift
>> evolution process, already once revised, is not fully implemented and may
>> never be?
>>
>>
>> Someone finding a bug/oversight in the compiler behavior does not compel
>> me to throw out the baby with the bathwater, no.
>>
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one. And no one just
> "forgot" to make the code above work; it simply can't be accommodated by
> the current mangling scheme. And--what's more--_no one seems to be bothered
> by it_. If the first sentence of a proposal can't be implemented, and no
> one cares (!), is the proposal fundamentally flawed or is it just some bug?
>
>
> The reason nobody cares much is because this is a degenerate case and is
> not actually how people want to use the feature.  You don’t see people
> writing identically named fileprivate methods in extensions of a type in
> different files either.  The purpose of the feature is not shadowing.  That
> is a side effect.  The purpose is to provide tight compiler-verified
> encapsulation.
>

Isn't supporting the following part and parcel of encapsulation?

```
class Foo {
  private var a: Int { return 42 }
}

class Bar : Foo {
  private var a: Int { return 43 }
  var b: Int { return a }
}

print(Bar().b) // 43
```

Tight compiler-verified encapsulation would, AFAIK, require that the 

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

Sometimes I feel like we need a winning sigil for this, one that would look 
good, it is not already taken and easy to type in all keyboards. 

Maybe we'll have to start looking at emojis :-)



> On Mar 21, 2017, at 9:13 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Mar 21, 2017, at 8:00 PM, Ben Rimmington  wrote:
>> 
>> Re: 
>> 
>>> On 21 Mar 2017, at 13:16, Matthew Johnson wrote:
>>> 
>>> I think the language is best served if all unbound members are accessible 
>>> using the same syntax.  IMO this proposal does the right thing by choosing 
>>> consistency with existing language features.  The current syntax for 
>>> unbound methods works and hasn't caused any confusions I'm aware of in 
>>> practice.  
>>> 
>>> I don't feel too strongly about what syntax we use as long as it's concise 
>>> and works for accessing all unbound members.  If people want to make the 
>>> case for using `#` instead of `.` to do this I won't object but I won't be 
>>> a vocal advocate either.  However, I think that should be an independent 
>>> proposal if somebody wants to pursue it rather than a bike shed on this 
>>> proposal which would only lead to inconsistency between key paths and 
>>> unbound methods if it succeeds.
>> 
>> A new syntax for key paths and function references could resolve:
>> 
>> * the "compound name syntax for nullary functions" problem;
>> 
>> 
>> * the source-breaking change of SE-0042 (if reconsidered for Swift 4);
>> 
> 
> I would like to see both of these problems resolved.  If somebody put 
> together a solid proposal for this I would probably support it (depending on 
> details of course).  
> 
>> 
>> -- Ben
>> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:31 PM, Drew Crawford 
wrote:

>
>
>
> On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one.
>
> To quote this in context:
>
> Scoped access level allows hiding implementation details of a class or a
> class extension at the class/extension level, instead of a file. It is a
> concise expression of the intent that a particular part of a class or
> extension definition is there only to implement a public API for other
> classes or extensions and must not be used directly anywhere outside of the
> scope of the class or the extension.
>
> I can see how an adversarial reading of the first sentence would argue
> that implementation details are not actually hidden by your example (which
> is, for the record, technically correct, the best kind of correct :-).
> However, the second sentence clarifies which kind of implementation details
> we mean to hide – the accidental use of members outside the scope.
>
These are inseparable parts of the whole. It would be absurd if I could not
have a private member in a subclass that happens to be identical to a
private member in a superclass. I can declare an internal member in an
extension to a public type that, in a different module, has an internal
member identically declared. Not being able to do so would be intolerably
broken. This goes to how essential is the encapsulation provided by
subtyping relationships, and how essential is the divide between public and
non-public members.

And this goes to my point: new `private` is enormously complicated, and now
you are trying to convince me that a certain shade of "hidden" is
sufficiently hidden. Proponents arguing for the usefulness of new `private`
show this or that use case that's enabled, but then disown the issues that
arise when the only logical interpretation of the rules leads to scenarios
that are difficult to reason about, use correctly, and (though this not
something that users would be bothered by) even support in the compiler.

> Your example does not involve hiding in that sense, so while it is
> interesting, and a bug, and should be fixed, etc., it does not thwart the
> practicable goal of the proposal.
>
> And no one just "forgot" to make the code above work; it simply can't be
> accommodated by the current mangling scheme.
>
> The Swift mangling scheme changes with some frequency, I know of around 3
> revs offhand and I do not work in that area often.  So holding this up as
> an immovable object is odd.
>
> Things would be different if we declared a stable ABI, but we did not, etc.
>
So that would be at least three revs that can't accommodate this feature. A
stable ABI may not be 4.0, but it isn't terribly far off. The window is
closing to fix the implementation, and it's not obvious that there is a
good solution.

> And--what's more--_no one seems to be bothered by it_.
>
> I volunteer to be bothered by it.  Where’s my cookie?
>
 . More if you volunteer to be sufficiently bothered to fix it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka  > wrote:
> 
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu >> > wrote:
>> 
>>> 
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 So, if four/five access modifiers are too many, which one is carrying the 
 least weight? Which one could be removed to simplify the scheme while 
 maintaining the most expressiveness? Which one doesn't fulfill even its 
 own stated goals? Well, one of the key goals of `private` was to allow 
 members to be encapsulated within an extension, hidden even from the type 
 being extended (and vice versa for members defined in the type). It says 
 so in the first sentence of SE-0025. As seen above in my discussion with 
 Charles Srstka, even supporters of `private` disagree with that motivation 
 to begin with. The kicker is, _it also doesn't work_. Try, for instance:
 
 ```
 struct Foo {
   private var bar: Int { return 42 }
 }
 
 extension Foo {
   private var bar: Int { return 43 }
 }
 ```
 
 The code above should compile and does not. If I understood correctly the 
 explanation from a core team member on this list, it's unclear if it can 
 be made to work without changing how mangling works, which I believe 
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
 `private` disagree on one of two key goals stated for new `private`; (b) 
 that goal was never accomplished, and making it work is not trivial; (c) 
 no one even complained about it, suggesting that it was a low-yield goal 
 in the first place.
>>> 
>>> Multiple people have already brought up cases in which they are using 
>>> ‘private’. The repeated mention of another, unrelated use case that was 
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>>> cases which have been presented. In fact, it rather makes it appear as if 
>>> the motivation to remove ‘private’ is based on a strange invocation of the 
>>> appeal-to-authority fallacy, rather than an actual improvement to the 
>>> language.
>>> 
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>>> without ripping out a lot of mangling code that is unlikely to be ripped 
>>> out before Swift 4. _And there is no evidence that anyone cares about this 
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If 
>>> this is not sufficient indication that the design of SE-0025 does not fit 
>>> with the overall direction of Swift, what would be?
>> 
>> Because there are other uses cases for ‘private', *not* involving 
>> extensions, which I *do* care about. The fact that part of the proposal was 
>> badly written (and really, that’s all this is
>> 
>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>> does not compile and there is not a timeline (afaict) for its compiling. It 
>> does not bother you that the 25th proposal considered in the Swift evolution 
>> process, already once revised, is not fully implemented and may never be?
> 
> Someone finding a bug/oversight in the compiler behavior does not compel me 
> to throw out the baby with the bathwater, no.
> 
> You're not hearing the argument. No one "accidentally" included this design 
> as part of SE-0025; it's sentence number one.

Or not. Here’s the actual text of the introductory paragraph:

"Scoped access level allows hiding implementation details of a class or a class 
extension at the class/extension level, instead of a file. It is a concise 
expression of the intent that a particular part of a class or extension 
definition is there only to implement a public API for other classes or 
extensions and must not be used directly anywhere outside of the scope of the 
class or the extension.”

So here we have “class or extension”, or some variant thereof, five separate 
times. It honestly reads like it originally just said “class”, and the author 
systematically went through it and added “or extension” to each of them to make 
sure his/her bases were covered. And didn’t quite succeed; the wording doesn’t 
account for value types.

And anyway, I’m not sure how you even get “extensions should be able to shadow 
private members” as Priority Number 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka  > wrote:
> 
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu >> > wrote:
>> 
>>> 
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 So, if four/five access modifiers are too many, which one is carrying the 
 least weight? Which one could be removed to simplify the scheme while 
 maintaining the most expressiveness? Which one doesn't fulfill even its 
 own stated goals? Well, one of the key goals of `private` was to allow 
 members to be encapsulated within an extension, hidden even from the type 
 being extended (and vice versa for members defined in the type). It says 
 so in the first sentence of SE-0025. As seen above in my discussion with 
 Charles Srstka, even supporters of `private` disagree with that motivation 
 to begin with. The kicker is, _it also doesn't work_. Try, for instance:
 
 ```
 struct Foo {
   private var bar: Int { return 42 }
 }
 
 extension Foo {
   private var bar: Int { return 43 }
 }
 ```
 
 The code above should compile and does not. If I understood correctly the 
 explanation from a core team member on this list, it's unclear if it can 
 be made to work without changing how mangling works, which I believe 
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
 `private` disagree on one of two key goals stated for new `private`; (b) 
 that goal was never accomplished, and making it work is not trivial; (c) 
 no one even complained about it, suggesting that it was a low-yield goal 
 in the first place.
>>> 
>>> Multiple people have already brought up cases in which they are using 
>>> ‘private’. The repeated mention of another, unrelated use case that was 
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>>> cases which have been presented. In fact, it rather makes it appear as if 
>>> the motivation to remove ‘private’ is based on a strange invocation of the 
>>> appeal-to-authority fallacy, rather than an actual improvement to the 
>>> language.
>>> 
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>>> without ripping out a lot of mangling code that is unlikely to be ripped 
>>> out before Swift 4. _And there is no evidence that anyone cares about this 
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If 
>>> this is not sufficient indication that the design of SE-0025 does not fit 
>>> with the overall direction of Swift, what would be?
>> 
>> Because there are other uses cases for ‘private', *not* involving 
>> extensions, which I *do* care about. The fact that part of the proposal was 
>> badly written (and really, that’s all this is
>> 
>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>> does not compile and there is not a timeline (afaict) for its compiling. It 
>> does not bother you that the 25th proposal considered in the Swift evolution 
>> process, already once revised, is not fully implemented and may never be?
> 
> Someone finding a bug/oversight in the compiler behavior does not compel me 
> to throw out the baby with the bathwater, no.
> 
> You're not hearing the argument. No one "accidentally" included this design 
> as part of SE-0025; it's sentence number one. And no one just "forgot" to 
> make the code above work; it simply can't be accommodated by the current 
> mangling scheme. And--what's more--_no one seems to be bothered by it_. If 
> the first sentence of a proposal can't be implemented, and no one cares (!), 
> is the proposal fundamentally flawed or is it just some bug?

The reason nobody cares much is because this is a degenerate case and is not 
actually how people want to use the feature.  You don’t see people writing 
identically named fileprivate methods in extensions of a type in different 
files either.  The purpose of the feature is not shadowing.  That is a side 
effect.  The purpose is to provide tight compiler-verified encapsulation.  
Nothing more, nothing less.

>> —it uses “class or extension” as a synonym for “any type declaration" when 
>> really, it makes just as much sense for structs to have private members as 
>> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

You're not hearing the argument. No one "accidentally" included this design as 
part of SE-0025; it's sentence number one. 
To quote this in context:

Scoped access level allows hiding implementation details of a class or a class 
extension at the class/extension level, instead of a file. It is a concise 
expression of the intent that a particular part of a class or extension 
definition is there only to implement a public API for other classes or 
extensions and must not be used directly anywhere outside of the scope of the 
class or the extension.

I can see how an adversarial reading of the first sentence would argue that 
implementation details are not actually hidden by your example (which is, for 
the record, technically correct, the best kind of correct :-).  However, the 
second sentence clarifies which kind of implementation details we mean to hide 
– the accidental use of members outside the scope.

Your example does not involve hiding in that sense, so while it is interesting, 
and a bug, and should be fixed, etc., it does not thwart the practicable goal 
of the proposal.

And no one just "forgot" to make the code above work; it simply can't be 
accommodated by the current mangling scheme. 
The Swift mangling scheme changes with some frequency, I know of around 3 revs 
offhand and I do not work in that area often.  So holding this up as an 
immovable object is odd.

Things would be different if we declared a stable ABI, but we did not, etc.

And--what's more--_no one seems to be bothered by it_.
I volunteer to be bothered by it.  Where’s my cookie?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
> wrote:
>
>> I am confused by this response. An argument in _support_ of new `private`
>> was that it is more in line with expectations of users coming from other
>> languages. In other some cases, such an argument might have its place.
>> However, as others have pointed out on this list, those other languages
>> don't have facilities like Swift's extensions, and therefore it was not a
>> very strong argument for new `private` to say that it better aligns with
>> user expectations coming from other languages.
>>
>> The underlying issue here (which I have now identified, thanks!) is what
>> motivates the use of extensions.  That question predates proposals, but the
>> Swift book provides the following motivation, which I have numbered for
>> ease of reference:
>>
>> 1. Extensions add new functionality to an existing class, structure,
>> enumeration, or protocol type.
>>
>> 2. This includes the ability to extend types for which you do not have
>> access to the original source code (known as retroactive modeling).
>>
>> 3. Extensions are similar to categories in Objective-C.
>>
>> It seems to me this motivation contemplates use “at some distance”, that
>> is we intend to create some semantically meaningful separation between the
>> declaration and the extension(s).  If we did not we could use MARK or some
>> other comment-based scheme to organize our class.
>>
>> 2 is explicitly at great distance, so we know the distance motivation is
>> well within scope.  1 refers to “an existing” type which implies a certain
>> level of functionality in the unextended type, and not merely a partial
>> implementation in the unextended type.  The record on 3 is more mixed (ObjC
>> programmers do occasionally use categories “closely-held” to group a few
>> methods together).  However ObjC also has the “distance” tradition:
>> categories cannot introduce new storage even when this is technically
>> trivial (within the same compilation unit for example), and this tradition
>> was continued under Swift with the new ABI.
>>
>> What I am suggesting is that the primary design purpose of an extension
>> is to create semantic distance between a declaration and the functionality
>> being added.
>>
>
> I'm not sure it is necessary for extensions to have a "primary design
> purpose." They serve many purposes. One use I have for them is as follows:
>
> ```
> struct A {
>   // Stuff here constitutes the "raison d'etre" for A.
> }
>
> extension A : B {
>   // In the course of implementing `A`, I have discovered that
>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>   // fulfills most of them already.
>   //
>   // So, I conform to B, as in so doing there are some practical
>   // advantages, such as gaining some default implementations.
>   //
>   // But, to conform, I may need to implement some methods
>   // not really essential for a functional `A`, but required nonetheless
>   // to conform to `B`.
>   //
>   // I implement them here in an extension; in so doing, I express
>   // the idea that I have, after implementing `A`, discovered its
>   // conformance to `B`, and I am here supplying the remaining
>   // implementations necessary for that conformance.
>   //
>   // That is, if `B` did not exist, neither would these functions here.
>   // But there may be some requirements of `B` that would be
>   // implemented in `A` whether or not `B` exists.
>   // Those are implemented above, in `struct A { ... }`.
> }
> ```
>
> I find this to be an eloquent way to separate concerns. It is a common
> pattern encouraged by code I admire written by others more skilled than me
> in Swift.
>
> A mechanism to hide variables from extensions is something that *furthers*
>> this design goal of extensions, rather than contradicts it.
>>
>
> This, I suppose, is an argument for you to take up with Charles.
>
>
>> I understand that some people use extensions as sort of an imitation
>> “partial class” but they simply aren’t (no storage) and we should introduce
>> a new feature if we want to have them.
>>
>> A core team member (I'm blanking on who) has pointed out that, in the
>> end, the only necessary access modifiers are public and not public (spelled
>> "internal" in Swift).
>>
>>
>> It is not clear to me how this squares with the decision in SE-0025 that
>> other access modifiers were necessary.  Can you clarify?
>>
>
> Why do you think SE-0025 decided that other access modifiers are
> necessary? It merely decided that having four was deemed, on balance,
> superior to having three. But the minimum number of access modifiers is, by
> definition, two. In the case of Swift those essentially have to be at the
> module boundary. Anything more finely diced 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:15 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Swift should only impose a preference when it's important to the speed,
> functionality, and safety of the language. I have yet to be convinced that
> there's a benefit to a scoped access level that fits anywhere in there.
>
> SE-0025 addresses these *specific* points.
>
> speed & safety:
>
> > Also, there is a greater danger of using private APIs if they do
> something similar to public APIs but are somehow more optimized (because
> they make additional assumptions about the internal state).
>
> functionality:
>
> > It forces a one class per file structure, which is very limiting.
> Putting related APIs and/or related implementations in the same file helps
> ensure consistency and reduces the time to find a particular API or
> implementation. This does not mean that the classes in the same file need
> to share otherwise hidden APIs, but there is no way to express such
> sharability with the current access levels.
>
>
>
>
> I have spent entire weeks of class trying to extoll the benefits, so
> breathlessly shared on these mailing lists, of how beautiful it is to have
> a scoped access level. I have yet to succeed.
>
> Perhaps this suggests scoped access modifiers are more comparable to e.g.
> “owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.
> Those features are breathtakingly difficult to teach, with design documents
> in the dozens of pages that are so dense I do not understand them.
>
> However, they solve hairy problems down in the dungeon somewhere, and most
> programmers do not actually need to know them to write their code.
>
> I don’t think scoped is quite to that level, but even if it were: if you
> like your visibility modifiers you can keep them!  There is no law that
> says you must use all the modifiers,
>
No, but you must understand what all of them mean to reason about code. You
can read and write a lot of useful Swift without understanding raw
pointers. You cannot reason about Swift code very well if you do not
understand access modifiers, especially `private`. If you're arguing that
new `private` is necessary to solve "hairy problems down in the dungeon
somewhere," it should certainly not be the so-called "soft" default that
comes with being named `private`. That is the diametrical opposite of how
it was pitched in SE-0025, where it's expected to be the overwhelmingly
most common choice.

And again, interoperability with C is a tentpole feature of Swift, so the
balance is different. Swift makes no such promises about encapsulation
within a module; in fact, IIUC it's a non-goal. So the balance between
power and teachability is distinctly different.

> and the availability of a feature does not “impose on all of us the
> personal code style preferences” of anyone.  Removing a feature does, and
> that’s the present proposal.
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
wrote:

>
> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>
> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>
>>
>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> So, if four/five access modifiers are too many, which one is carrying
>>> the least weight? Which one could be removed to simplify the scheme while
>>> maintaining the most expressiveness? Which one doesn't fulfill even its own
>>> stated goals? Well, one of the key goals of `private` was to allow members
>>> to be encapsulated within an extension, hidden even from the type being
>>> extended (and vice versa for members defined in the type). It says so in
>>> the first sentence of SE-0025. As seen above in my discussion with Charles
>>> Srstka, even supporters of `private` disagree with that motivation to begin
>>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>>
>>> ```
>>> struct Foo {
>>>   private var bar: Int { return 42 }
>>> }
>>>
>>> extension Foo {
>>>   private var bar: Int { return 43 }
>>> }
>>> ```
>>>
>>> The code above should compile and does not. If I understood correctly
>>> the explanation from a core team member on this list, it's unclear if it
>>> can be made to work without changing how mangling works, which I believe
>>> impacts ABI and is not trivial at all. Thus, (a) even proponents of new
>>> `private` disagree on one of two key goals stated for new `private`; (b)
>>> that goal was never accomplished, and making it work is not trivial; (c) no
>>> one even complained about it, suggesting that it was a low-yield goal in
>>> the first place.
>>>
>>>
>>> Multiple people have already brought up cases in which they are using
>>> ‘private’. The repeated mention of another, unrelated use case that was
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use
>>> cases which have been presented. In fact, it rather makes it appear as if
>>> the motivation to remove ‘private’ is based on a strange invocation of the
>>> appeal-to-authority fallacy, rather than an actual improvement to the
>>> language.
>>>
>>
>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>> implemented. And as I said above, IIUC, it cannot be fully implemented
>> without ripping out a lot of mangling code that is unlikely to be ripped
>> out before Swift 4. _And there is no evidence that anyone cares about this
>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>> this is not sufficient indication that the design of SE-0025 does not fit
>> with the overall direction of Swift, what would be?
>>
>>
>> Because there are other uses cases for ‘private', *not* involving
>> extensions, which I *do* care about. The fact that part of the proposal was
>> badly written (and really, that’s all this is
>>
>
> Huh? The code above *should compile*--that is a primary aim for SE-0025.
> It does not compile and there is not a timeline (afaict) for its compiling.
> It does not bother you that the 25th proposal considered in the Swift
> evolution process, already once revised, is not fully implemented and may
> never be?
>
>
> Someone finding a bug/oversight in the compiler behavior does not compel
> me to throw out the baby with the bathwater, no.
>

You're not hearing the argument. No one "accidentally" included this design
as part of SE-0025; it's sentence number one. And no one just "forgot" to
make the code above work; it simply can't be accommodated by the current
mangling scheme. And--what's more--_no one seems to be bothered by it_. If
the first sentence of a proposal can't be implemented, and no one cares
(!), is the proposal fundamentally flawed or is it just some bug?

> —it uses “class or extension” as a synonym for “any type declaration" when
>> really, it makes just as much sense for structs to have private members as
>> classes. Stuff happens!) does not invalidate the other use cases. And yes,
>> I’m aware that my coding style may differ from other people, who may use
>> the language in a different way. We shouldn’t break *their* use cases,
>> either.
>>
>
> We shouldn't break their use cases _without good reason_, but we shouldn't
> hesitate to break their use cases if (a) there is an extremely justifiable
> reason for it; and (b) the migration path is straightforward; and
> (preferably) also (c) the breakage is relatively uncommon. I happen to
> think those criteria are met for the reasons I've outlined extensively
> above, and you may certainly quibble with that conclusion
>
>
> We’re simply going to have to disagree here.
>
> Charles
>
>
___
swift-evolution mailing list

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution 
(swift-evolution@swift.org) wrote:

Swift should only impose a preference when it's important to the speed, 
functionality, and safety of the language. I have yet to be convinced that 
there's a benefit to a scoped access level that fits anywhere in there.
SE-0025 addresses these *specific* points.

speed & safety:

> Also, there is a greater danger of using private APIs if they do something 
> similar to public APIs but are somehow more optimized (because they make 
> additional assumptions about the internal state).
functionality:

> It forces a one class per file structure, which is very limiting. Putting 
> related APIs and/or related implementations in the same file helps ensure 
> consistency and reduces the time to find a particular API or implementation. 
> This does not mean that the classes in the same file need to share otherwise 
> hidden APIs, but there is no way to express such sharability with the current 
> access levels.



I have spent entire weeks of class trying to extoll the benefits, so 
breathlessly shared on these mailing lists, of how beautiful it is to have a 
scoped access level. I have yet to succeed.
Perhaps this suggests scoped access modifiers are more comparable to e.g. 
“owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.  Those 
features are breathtakingly difficult to teach, with design documents in the 
dozens of pages that are so dense I do not understand them.

However, they solve hairy problems down in the dungeon somewhere, and most 
programmers do not actually need to know them to write their code.

I don’t think scoped is quite to that level, but even if it were: if you like 
your visibility modifiers you can keep them!  There is no law that says you 
must use all the modifiers, and the availability of a feature does not “impose 
on all of us the personal code style preferences” of anyone.  Removing a 
feature does, and that’s the present proposal.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear to me how this squares with the decision in SE-0025 that
> other access modifiers were necessary.  Can you clarify?
>

I believe the reference is to this comment by Slava Pestov on 2017-02-16:

While we’re bikeshedding, I’m going to add my two cents. Hold on to your
> hat
> because this might be controversial here.
>
> I think both ‘private’ and ‘fileprivate’ are unnecessary complications
> that
> only serve to clutter the language.
>


It would make a lot more sense to just have internal and public only. No
> private, no fileprivate, no lineprivate, no protected. It’s all silly.


https://www.mail-archive.com/swift-evolution@swift.org/msg21766.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > > wrote:
> 
>> 
>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> So, if four/five access modifiers are too many, which one is carrying the 
>>> least weight? Which one could be removed to simplify the scheme while 
>>> maintaining the most expressiveness? Which one doesn't fulfill even its own 
>>> stated goals? Well, one of the key goals of `private` was to allow members 
>>> to be encapsulated within an extension, hidden even from the type being 
>>> extended (and vice versa for members defined in the type). It says so in 
>>> the first sentence of SE-0025. As seen above in my discussion with Charles 
>>> Srstka, even supporters of `private` disagree with that motivation to begin 
>>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>> 
>>> ```
>>> struct Foo {
>>>   private var bar: Int { return 42 }
>>> }
>>> 
>>> extension Foo {
>>>   private var bar: Int { return 43 }
>>> }
>>> ```
>>> 
>>> The code above should compile and does not. If I understood correctly the 
>>> explanation from a core team member on this list, it's unclear if it can be 
>>> made to work without changing how mangling works, which I believe impacts 
>>> ABI and is not trivial at all. Thus, (a) even proponents of new `private` 
>>> disagree on one of two key goals stated for new `private`; (b) that goal 
>>> was never accomplished, and making it work is not trivial; (c) no one even 
>>> complained about it, suggesting that it was a low-yield goal in the first 
>>> place.
>> 
>> Multiple people have already brought up cases in which they are using 
>> ‘private’. The repeated mention of another, unrelated use case that was 
>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>> cases which have been presented. In fact, it rather makes it appear as if 
>> the motivation to remove ‘private’ is based on a strange invocation of the 
>> appeal-to-authority fallacy, rather than an actual improvement to the 
>> language.
>> 
>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>> without ripping out a lot of mangling code that is unlikely to be ripped out 
>> before Swift 4. _And there is no evidence that anyone cares about this flaw; 
>> in fact, you are saying as much, that you do not care at all!_ If this is 
>> not sufficient indication that the design of SE-0025 does not fit with the 
>> overall direction of Swift, what would be?
> 
> Because there are other uses cases for ‘private', *not* involving extensions, 
> which I *do* care about. The fact that part of the proposal was badly written 
> (and really, that’s all this is
> 
> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
> does not compile and there is not a timeline (afaict) for its compiling. It 
> does not bother you that the 25th proposal considered in the Swift evolution 
> process, already once revised, is not fully implemented and may never be?

Someone finding a bug/oversight in the compiler behavior does not compel me to 
throw out the baby with the bathwater, no.

> —it uses “class or extension” as a synonym for “any type declaration" when 
> really, it makes just as much sense for structs to have private members as 
> classes. Stuff happens!) does not invalidate the other use cases. And yes, 
> I’m aware that my coding style may differ from other people, who may use the 
> language in a different way. We shouldn’t break *their* use cases, either.
> 
> We shouldn't break their use cases _without good reason_, but we shouldn't 
> hesitate to break their use cases if (a) there is an extremely justifiable 
> reason for it; and (b) the migration path is straightforward; and 
> (preferably) also (c) the breakage is relatively uncommon. I happen to think 
> those criteria are met for the reasons I've outlined extensively above, and 
> you may certainly quibble with that conclusion

We’re simply going to have to disagree here.

Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford  
>> wrote:
 I am confused by this response. An argument in _support_ of new `private` 
 was that it is more in line with expectations of users coming from other 
 languages. In other some cases, such an argument might have its place. 
 However, as others have pointed out on this list, those other languages 
 don't have facilities like Swift's extensions, and therefore it was not a 
 very strong argument for new `private` to say that it better aligns with 
 user expectations coming from other languages.
>>> 
>>> The underlying issue here (which I have now identified, thanks!) is what 
>>> motivates the use of extensions.  That question predates proposals, but the 
>>> Swift book provides the following motivation, which I have numbered for 
>>> ease of reference:
>>> 
>>> 1. Extensions add new functionality to an existing class, structure, 
>>> enumeration, or protocol type. 
>>> 2. This includes the ability to extend types for which you do not have 
>>> access to the original source code (known as retroactive modeling). 
>>> 
>>> 3. Extensions are similar to categories in Objective-C.
>>> 
>> 
>> It seems to me this motivation contemplates use “at some distance”, that is 
>> we intend to create some semantically meaningful separation between the 
>> declaration and the extension(s).  If we did not we could use MARK or some 
>> other comment-based scheme to organize our class.
>> 
>> 2 is explicitly at great distance, so we know the distance motivation is 
>> well within scope.  1 refers to “an existing” type which implies a certain 
>> level of functionality in the unextended type, and not merely a partial 
>> implementation in the unextended type.  The record on 3 is more mixed (ObjC 
>> programmers do occasionally use categories “closely-held” to group a few 
>> methods together).  However ObjC also has the “distance” tradition: 
>> categories cannot introduce new storage even when this is technically 
>> trivial (within the same compilation unit for example), and this tradition 
>> was continued under Swift with the new ABI.
>> 
>> What I am suggesting is that the primary design purpose of an extension is 
>> to create semantic distance between a declaration and the functionality 
>> being added.
> 
> I'm not sure it is necessary for extensions to have a "primary design 
> purpose." They serve many purposes. One use I have for them is as follows:
> 
> ```
> struct A {
>   // Stuff here constitutes the "raison d'etre" for A.
> }
> 
> extension A : B {
>   // In the course of implementing `A`, I have discovered that
>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>   // fulfills most of them already.
>   //
>   // So, I conform to B, as in so doing there are some practical
>   // advantages, such as gaining some default implementations.
>   //
>   // But, to conform, I may need to implement some methods
>   // not really essential for a functional `A`, but required nonetheless
>   // to conform to `B`.
>   //
>   // I implement them here in an extension; in so doing, I express
>   // the idea that I have, after implementing `A`, discovered its
>   // conformance to `B`, and I am here supplying the remaining
>   // implementations necessary for that conformance.
>   //
>   // That is, if `B` did not exist, neither would these functions here.
>   // But there may be some requirements of `B` that would be
>   // implemented in `A` whether or not `B` exists.
>   // Those are implemented above, in `struct A { ... }`.
> }
> ```
> 
> I find this to be an eloquent way to separate concerns. It is a common 
> pattern encouraged by code I admire written by others more skilled than me in 
> Swift.
> 
>> A mechanism to hide variables from extensions is something that *furthers* 
>> this design goal of extensions, rather than contradicts it.
> 
> This, I suppose, is an argument for you to take up with Charles.
>  
>> I understand that some people use extensions as sort of an imitation 
>> “partial class” but they simply aren’t (no storage) and we should introduce 
>> a new feature if we want to have them.
>> 
>>> A core team member (I'm blanking on who) has pointed out that, in the end, 
>>> the only necessary access modifiers are public and not public (spelled 
>>> "internal" in Swift).
>> 
>> 
>> It is not clear to me how this squares with the decision in SE-0025 that 
>> other access modifiers were necessary.  Can you clarify?
> 
> Why do you think SE-0025 decided that other access modifiers are necessary? 
> It merely decided that having four was deemed, on balance, superior to having 
> three. But the minimum number of access modifiers is, by definition, two. In 
> the case of Swift those essentially have to be at the module boundary. 
> Anything more finely diced than 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> So, if four/five access modifiers are too many, which one is carrying the
>> least weight? Which one could be removed to simplify the scheme while
>> maintaining the most expressiveness? Which one doesn't fulfill even its own
>> stated goals? Well, one of the key goals of `private` was to allow members
>> to be encapsulated within an extension, hidden even from the type being
>> extended (and vice versa for members defined in the type). It says so in
>> the first sentence of SE-0025. As seen above in my discussion with Charles
>> Srstka, even supporters of `private` disagree with that motivation to begin
>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>>
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>>
>> The code above should compile and does not. If I understood correctly the
>> explanation from a core team member on this list, it's unclear if it can be
>> made to work without changing how mangling works, which I believe impacts
>> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
>> disagree on one of two key goals stated for new `private`; (b) that goal
>> was never accomplished, and making it work is not trivial; (c) no one even
>> complained about it, suggesting that it was a low-yield goal in the first
>> place.
>>
>>
>> Multiple people have already brought up cases in which they are using
>> ‘private’. The repeated mention of another, unrelated use case that was
>> mentioned in the SE-0025 proposal does not invalidate the real-world use
>> cases which have been presented. In fact, it rather makes it appear as if
>> the motivation to remove ‘private’ is based on a strange invocation of the
>> appeal-to-authority fallacy, rather than an actual improvement to the
>> language.
>>
>
> I'm not sure how to respond to this. SE-0025, as designed, is not fully
> implemented. And as I said above, IIUC, it cannot be fully implemented
> without ripping out a lot of mangling code that is unlikely to be ripped
> out before Swift 4. _And there is no evidence that anyone cares about this
> flaw; in fact, you are saying as much, that you do not care at all!_ If
> this is not sufficient indication that the design of SE-0025 does not fit
> with the overall direction of Swift, what would be?
>
>
> Because there are other uses cases for ‘private', *not* involving
> extensions, which I *do* care about. The fact that part of the proposal was
> badly written (and really, that’s all this is
>

Huh? The code above *should compile*--that is a primary aim for SE-0025. It
does not compile and there is not a timeline (afaict) for its compiling. It
does not bother you that the 25th proposal considered in the Swift
evolution process, already once revised, is not fully implemented and may
never be?

—it uses “class or extension” as a synonym for “any type declaration" when
> really, it makes just as much sense for structs to have private members as
> classes. Stuff happens!) does not invalidate the other use cases. And yes,
> I’m aware that my coding style may differ from other people, who may use
> the language in a different way. We shouldn’t break *their* use cases,
> either.
>

We shouldn't break their use cases _without good reason_, but we shouldn't
hesitate to break their use cases if (a) there is an extremely justifiable
reason for it; and (b) the migration path is straightforward; and
(preferably) also (c) the breakage is relatively uncommon. I happen to
think those criteria are met for the reasons I've outlined extensively
above, and you may certainly quibble with that conclusion--but saying that
we shouldn't break anyone's use case, period, is not at all reasonable.

Many people used to argue against early returns as being tantamount to
>> littering one’s code with GOTO statements willy-nilly, instead advocating
>> for assigning to a return variable which would then be returned in the last
>> line of the function. Swift explicitly rejects this view, offering
>> constructs such as the guard statement and the error-handling mechanism
>> which specifically encourage early returns. However, I don’t see people
>> using the non-acceptance of this particular argument against GOTOs as an
>> argument for eliminating all structured flow control from the language.
>>
>
> I don't follow. Which people have argued against structured control flow
> in Swift?
>
>
> No one has. That’s the point!
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Smart KeyPaths

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 21, 2017, at 8:00 PM, Ben Rimmington  wrote:
> 
> Re: 
> 
>> On 21 Mar 2017, at 13:16, Matthew Johnson wrote:
>> 
>> I think the language is best served if all unbound members are accessible 
>> using the same syntax.  IMO this proposal does the right thing by choosing 
>> consistency with existing language features.  The current syntax for unbound 
>> methods works and hasn't caused any confusions I'm aware of in practice.  
>> 
>> I don't feel too strongly about what syntax we use as long as it's concise 
>> and works for accessing all unbound members.  If people want to make the 
>> case for using `#` instead of `.` to do this I won't object but I won't be a 
>> vocal advocate either.  However, I think that should be an independent 
>> proposal if somebody wants to pursue it rather than a bike shed on this 
>> proposal which would only lead to inconsistency between key paths and 
>> unbound methods if it succeeds.
> 
> A new syntax for key paths and function references could resolve:
> 
> * the "compound name syntax for nullary functions" problem;
>  
> 
> 
> * the source-breaking change of SE-0042 (if reconsidered for Swift 4);
>  
> 

I would like to see both of these problems resolved.  If somebody put together 
a solid proposal for this I would probably support it (depending on details of 
course).  

> 
> -- Ben
> 

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

Re: [swift-evolution] Smart KeyPaths

[Ben Rimmington via swift-evolution]

Re: 

> On 21 Mar 2017, at 13:16, Matthew Johnson wrote:
> 
> I think the language is best served if all unbound members are accessible 
> using the same syntax.  IMO this proposal does the right thing by choosing 
> consistency with existing language features.  The current syntax for unbound 
> methods works and hasn't caused any confusions I'm aware of in practice.  
> 
> I don't feel too strongly about what syntax we use as long as it's concise 
> and works for accessing all unbound members.  If people want to make the case 
> for using `#` instead of `.` to do this I won't object but I won't be a vocal 
> advocate either.  However, I think that should be an independent proposal if 
> somebody wants to pursue it rather than a bike shed on this proposal which 
> would only lead to inconsistency between key paths and unbound methods if it 
> succeeds.

A new syntax for key paths and function references could resolve:

* the "compound name syntax for nullary functions" problem;
  


* the source-breaking change of SE-0042 (if reconsidered for Swift 4);
  


-- Ben

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> So, if four/five access modifiers are too many, which one is carrying the 
>> least weight? Which one could be removed to simplify the scheme while 
>> maintaining the most expressiveness? Which one doesn't fulfill even its own 
>> stated goals? Well, one of the key goals of `private` was to allow members 
>> to be encapsulated within an extension, hidden even from the type being 
>> extended (and vice versa for members defined in the type). It says so in the 
>> first sentence of SE-0025. As seen above in my discussion with Charles 
>> Srstka, even supporters of `private` disagree with that motivation to begin 
>> with. The kicker is, _it also doesn't work_. Try, for instance:
>> 
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>> 
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>> 
>> The code above should compile and does not. If I understood correctly the 
>> explanation from a core team member on this list, it's unclear if it can be 
>> made to work without changing how mangling works, which I believe impacts 
>> ABI and is not trivial at all. Thus, (a) even proponents of new `private` 
>> disagree on one of two key goals stated for new `private`; (b) that goal was 
>> never accomplished, and making it work is not trivial; (c) no one even 
>> complained about it, suggesting that it was a low-yield goal in the first 
>> place.
> 
> Multiple people have already brought up cases in which they are using 
> ‘private’. The repeated mention of another, unrelated use case that was 
> mentioned in the SE-0025 proposal does not invalidate the real-world use 
> cases which have been presented. In fact, it rather makes it appear as if the 
> motivation to remove ‘private’ is based on a strange invocation of the 
> appeal-to-authority fallacy, rather than an actual improvement to the 
> language.
> 
> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
> implemented. And as I said above, IIUC, it cannot be fully implemented 
> without ripping out a lot of mangling code that is unlikely to be ripped out 
> before Swift 4. _And there is no evidence that anyone cares about this flaw; 
> in fact, you are saying as much, that you do not care at all!_ If this is not 
> sufficient indication that the design of SE-0025 does not fit with the 
> overall direction of Swift, what would be?

Because there are other uses cases for ‘private', *not* involving extensions, 
which I *do* care about. The fact that part of the proposal was badly written 
(and really, that’s all this is—it uses “class or extension” as a synonym for 
“any type declaration" when really, it makes just as much sense for structs to 
have private members as classes. Stuff happens!) does not invalidate the other 
use cases. And yes, I’m aware that my coding style may differ from other 
people, who may use the language in a different way. We shouldn’t break *their* 
use cases, either.

> Many people used to argue against early returns as being tantamount to 
> littering one’s code with GOTO statements willy-nilly, instead advocating for 
> assigning to a return variable which would then be returned in the last line 
> of the function. Swift explicitly rejects this view, offering constructs such 
> as the guard statement and the error-handling mechanism which specifically 
> encourage early returns. However, I don’t see people using the non-acceptance 
> of this particular argument against GOTOs as an argument for eliminating all 
> structured flow control from the language.
> 
> I don't follow. Which people have argued against structured control flow in 
> Swift?

No one has. That’s the point!

Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> So, if four/five access modifiers are too many, which one is carrying the
> least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its own
> stated goals? Well, one of the key goals of `private` was to allow members
> to be encapsulated within an extension, hidden even from the type being
> extended (and vice versa for members defined in the type). It says so in
> the first sentence of SE-0025. As seen above in my discussion with Charles
> Srstka, even supporters of `private` disagree with that motivation to begin
> with. The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly the
> explanation from a core team member on this list, it's unclear if it can be
> made to work without changing how mangling works, which I believe impacts
> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
> disagree on one of two key goals stated for new `private`; (b) that goal
> was never accomplished, and making it work is not trivial; (c) no one even
> complained about it, suggesting that it was a low-yield goal in the first
> place.
>
>
> Multiple people have already brought up cases in which they are using
> ‘private’. The repeated mention of another, unrelated use case that was
> mentioned in the SE-0025 proposal does not invalidate the real-world use
> cases which have been presented. In fact, it rather makes it appear as if
> the motivation to remove ‘private’ is based on a strange invocation of the
> appeal-to-authority fallacy, rather than an actual improvement to the
> language.
>

I'm not sure how to respond to this. SE-0025, as designed, is not fully
implemented. And as I said above, IIUC, it cannot be fully implemented
without ripping out a lot of mangling code that is unlikely to be ripped
out before Swift 4. _And there is no evidence that anyone cares about this
flaw; in fact, you are saying as much, that you do not care at all!_ If
this is not sufficient indication that the design of SE-0025 does not fit
with the overall direction of Swift, what would be?


Many people used to argue against early returns as being tantamount to
> littering one’s code with GOTO statements willy-nilly, instead advocating
> for assigning to a return variable which would then be returned in the last
> line of the function. Swift explicitly rejects this view, offering
> constructs such as the guard statement and the error-handling mechanism
> which specifically encourage early returns. However, I don’t see people
> using the non-acceptance of this particular argument against GOTOs as an
> argument for eliminating all structured flow control from the language.
>

I don't follow. Which people have argued against structured control flow in
Swift? And what does that have to do with rolling back a partially
implemented proposal?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

On Tue, Mar 21, 2017, at 07:44 PM, Drew Crawford via swift-evolution wrote:
>> When new `private` and `fileprivate` were shipped, there were
>> numerous questions asked by users on forums such as Stack Overflow
> 

> And before they were shipped, there were people asking for a scoped
> modifier.  And when we change them again, what questions will that
> generate?  So I don’t see what we are accomplishing with this line of
> inquiry.
> 

>> You see the new access modifiers described, for example, as something
>> that "take[s] some getting used to." Rather damning as a euphemism,
>> don't you think?
> Not at all.  We could describe strong typing, or optionals, enums,
> pattern matching, etc., in this way.  ARC in particular is “difficult
> to teach” but we should not get rid of it, it solves a safety problem.
> A scoped access modifier is similar.


These two points are where I have to jump in. As someone who actually
teaches Swift, and not just lectures others about it on the mailing
lists, both of these arguments are terribly fallacious. Core Swift
features like optionals are fundamental to the idea of the language,
that have semantic meaning and impact on  compiled code.


People are thrilled to learn how to use enums because they make for a
better time writing code. These access modifier are can only charitably
be called code flavor. I have spent entire weeks of class trying to
extoll the benefits, so breathlessly shared on these mailing lists, of
how beautiful it is to have a scoped access level. I have yet to
succeed. They frustrate readers and they are a constant source of
roadblocks for the inexperienced.


Segregating private and fileprivate are, at best, a distraction, and at
worst are actively imposing on all of us the personal code style
preferences of those that were most active on the mailing lists while
Swift 2 was open.


It doesn't matter if desire for using extensions is the root of the
problem. Swift should only impose a preference when it's important to
the speed, functionality, and safety of the language. I have yet to be
convinced that there's a benefit to a scoped access level that fits
anywhere in there.


Best,

  Zach Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
wrote:

> I am confused by this response. An argument in _support_ of new `private`
> was that it is more in line with expectations of users coming from other
> languages. In other some cases, such an argument might have its place.
> However, as others have pointed out on this list, those other languages
> don't have facilities like Swift's extensions, and therefore it was not a
> very strong argument for new `private` to say that it better aligns with
> user expectations coming from other languages.
>
> The underlying issue here (which I have now identified, thanks!) is what
> motivates the use of extensions.  That question predates proposals, but the
> Swift book provides the following motivation, which I have numbered for
> ease of reference:
>
> 1. Extensions add new functionality to an existing class, structure,
> enumeration, or protocol type.
>
> 2. This includes the ability to extend types for which you do not have
> access to the original source code (known as retroactive modeling).
>
> 3. Extensions are similar to categories in Objective-C.
>
> It seems to me this motivation contemplates use “at some distance”, that
> is we intend to create some semantically meaningful separation between the
> declaration and the extension(s).  If we did not we could use MARK or some
> other comment-based scheme to organize our class.
>
> 2 is explicitly at great distance, so we know the distance motivation is
> well within scope.  1 refers to “an existing” type which implies a certain
> level of functionality in the unextended type, and not merely a partial
> implementation in the unextended type.  The record on 3 is more mixed (ObjC
> programmers do occasionally use categories “closely-held” to group a few
> methods together).  However ObjC also has the “distance” tradition:
> categories cannot introduce new storage even when this is technically
> trivial (within the same compilation unit for example), and this tradition
> was continued under Swift with the new ABI.
>
> What I am suggesting is that the primary design purpose of an extension is
> to create semantic distance between a declaration and the functionality
> being added.
>

I'm not sure it is necessary for extensions to have a "primary design
purpose." They serve many purposes. One use I have for them is as follows:

```
struct A {
  // Stuff here constitutes the "raison d'etre" for A.
}

extension A : B {
  // In the course of implementing `A`, I have discovered that
  // `A` can fulfill the semantic guarantees of `B`, and in fact
  // fulfills most of them already.
  //
  // So, I conform to B, as in so doing there are some practical
  // advantages, such as gaining some default implementations.
  //
  // But, to conform, I may need to implement some methods
  // not really essential for a functional `A`, but required nonetheless
  // to conform to `B`.
  //
  // I implement them here in an extension; in so doing, I express
  // the idea that I have, after implementing `A`, discovered its
  // conformance to `B`, and I am here supplying the remaining
  // implementations necessary for that conformance.
  //
  // That is, if `B` did not exist, neither would these functions here.
  // But there may be some requirements of `B` that would be
  // implemented in `A` whether or not `B` exists.
  // Those are implemented above, in `struct A { ... }`.
}
```

I find this to be an eloquent way to separate concerns. It is a common
pattern encouraged by code I admire written by others more skilled than me
in Swift.

A mechanism to hide variables from extensions is something that *furthers*
> this design goal of extensions, rather than contradicts it.
>

This, I suppose, is an argument for you to take up with Charles.


> I understand that some people use extensions as sort of an imitation
> “partial class” but they simply aren’t (no storage) and we should introduce
> a new feature if we want to have them.
>
> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear to me how this squares with the decision in SE-0025 that
> other access modifiers were necessary.  Can you clarify?
>

Why do you think SE-0025 decided that other access modifiers are necessary?
It merely decided that having four was deemed, on balance, superior to
having three. But the minimum number of access modifiers is, by definition,
two. In the case of Swift those essentially have to be at the module
boundary. Anything more finely diced than that and you are balancing
expressivity and complexity. I would not be opposed, incidentally, to
stripping back access modifiers to two: `internal` (or maybe eliminate that
explicit annotation altogether) and `public`.

When new `private` and `fileprivate` were shipped, there were numerous
> questions asked by users on forums such as Stack Overflow

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Christopher Kornher via swift-evolution]

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
-1 

Is the problem being addressed significant enough to warrant a change to Swift?
Not on its own. I believe that it would be better for the community to handle 
this as part of a thorough look at Sub Modules and code organization. It is 
possible that this will be modified yet again when submodules/packages are 
addressed, creating yet more churn.

Access modifiers should not much of an issue for beginners and small projects. 
The current rules are useful for large and security-oriented projects. See the 
response by Drew Crawford.

Does this proposal fit well with the feel and direction of Swift?
File scoping has always seemed like a “C legacy” feature. It encourages large 
files, which is a problem in MacOS and iOS already. This proposal does nothing 
to decrease file size and makes file scoping the only way to get private scope. 
File-based scoping also discourages or at least complicates the development of 
non file-based and non-textual representations of Swift code

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
C and other macro-assemblers. Isn’t there a better model out there somewhere?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I read through the proposal, which is pretty straightforward.

> On Mar 20, 2017, at 5:54 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its own 
> stated goals? Well, one of the key goals of `private` was to allow members to 
> be encapsulated within an extension, hidden even from the type being extended 
> (and vice versa for members defined in the type). It says so in the first 
> sentence of SE-0025. As seen above in my discussion with Charles Srstka, even 
> supporters of `private` disagree with that motivation to begin with. The 
> kicker is, _it also doesn't work_. Try, for instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can be 
> made to work without changing how mangling works, which I believe impacts ABI 
> and is not trivial at all. Thus, (a) even proponents of new `private` 
> disagree on one of two key goals stated for new `private`; (b) that goal was 
> never accomplished, and making it work is not trivial; (c) no one even 
> complained about it, suggesting that it was a low-yield goal in the first 
> place.

Multiple people have already brought up cases in which they are using 
‘private’. The repeated mention of another, unrelated use case that was 
mentioned in the SE-0025 proposal does not invalidate the real-world use cases 
which have been presented. In fact, it rather makes it appear as if the 
motivation to remove ‘private’ is based on a strange invocation of the 
appeal-to-authority fallacy, rather than an actual improvement to the language.

Many people used to argue against early returns as being tantamount to 
littering one’s code with GOTO statements willy-nilly, instead advocating for 
assigning to a return variable which would then be returned in the last line of 
the function. Swift explicitly rejects this view, offering constructs such as 
the guard statement and the error-handling mechanism which specifically 
encourage early returns. However, I don’t see people using the non-acceptance 
of this particular argument against GOTOs as an argument for eliminating all 
structured flow control from the language.

Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

I am confused by this response. An argument in _support_ of new `private` was 
that it is more in line with expectations of users coming from other languages. 
In other some cases, such an argument might have its place. However, as others 
have pointed out on this list, those other languages don't have facilities like 
Swift's extensions, and therefore it was not a very strong argument for new 
`private` to say that it better aligns with user expectations coming from other 
languages.
The underlying issue here (which I have now identified, thanks!) is what 
motivates the use of extensions.  That question predates proposals, but the 
Swift book provides the following motivation, which I have numbered for ease of 
reference:

1. Extensions add new functionality to an existing class, structure, 
enumeration, or protocol type. 
2. This includes the ability to extend types for which you do not have access 
to the original source code (known as retroactive modeling). 

3. Extensions are similar to categories in Objective-C.

It seems to me this motivation contemplates use “at some distance”, that is we 
intend to create some semantically meaningful separation between the 
declaration and the extension(s).  If we did not we could use MARK or some 
other comment-based scheme to organize our class.

2 is explicitly at great distance, so we know the distance motivation is well 
within scope.  1 refers to “an existing” type which implies a certain level of 
functionality in the unextended type, and not merely a partial implementation 
in the unextended type.  The record on 3 is more mixed (ObjC programmers do 
occasionally use categories “closely-held” to group a few methods together).  
However ObjC also has the “distance” tradition: categories cannot introduce new 
storage even when this is technically trivial (within the same compilation unit 
for example), and this tradition was continued under Swift with the new ABI.

What I am suggesting is that the primary design purpose of an extension is to 
create semantic distance between a declaration and the functionality being 
added.  A mechanism to hide variables from extensions is something that 
*furthers* this design goal of extensions, rather than contradicts it.

I understand that some people use extensions as sort of an imitation “partial 
class” but they simply aren’t (no storage) and we should introduce a new 
feature if we want to have them.

A core team member (I'm blanking on who) has pointed out that, in the end, the 
only necessary access modifiers are public and not public (spelled "internal" 
in Swift).

It is not clear to me how this squares with the decision in SE-0025 that other 
access modifiers were necessary.  Can you clarify?

When new `private` and `fileprivate` were shipped, there were numerous 
questions asked by users on forums such as Stack Overflow

And before they were shipped, there were people asking for a scoped modifier.  
And when we change them again, what questions will that generate?  So I don’t 
see what we are accomplishing with this line of inquiry.

You see the new access modifiers described, for example, as something that 
"take[s] some getting used to." Rather damning as a euphemism, don't you think? 
Not at all.  We could describe strong typing, or optionals, enums, pattern 
matching, etc., in this way.  ARC in particular is “difficult to teach” but we 
should not get rid of it, it solves a safety problem.  A scoped access modifier 
is similar.

When the Swift core team approved the proposal, they expressed the belief that 
`fileprivate` would be rarely used. This has turned out plainly and 
indisputably not to be true. It is clear that they expected Swift to have, 
after SE-0025 (and before `open`), three commonly used access modifiers and one 
vestigial one. Instead we have four/five commonly used access modifiers. Thus, 
the complexity of the current system is _not_ what was envisioned at the time 
of approval for SE-0025, and the resulting system should be re-evaluated in 
light of this real-world data. 

The only citation I can find on this topic is the cryptic “fileprivate is 
rarely needed” in the context of “rare enough to be explicit”.   I submit that 
according to previously-presented data, I do use it rarely, less often than the 
other modifiers, certainly in a manner consistent with being explicit.  I do 
not see how we jump from that fact pattern to “plainly and indisputably… _not_ 
what was envisioned at the time”.  It is not plain and I do dispute it.

The code above should compile and does not.

It is not clear to me how this is especially relevant.  The point of a scoped 
access modifier is to prevent programs from compiling when they should not.  
Here is a program that does not compile when it should; that’s a bug, but it 
doesn’t go to whether the scoped people are caught with their pants down or 
working from bad safety assumptions.  It’s just a complier crasher.

(a) even proponents of new `private` 

Re: [swift-evolution] Smart KeyPaths

[Haravikk via swift-evolution]

> On 21 Mar 2017, at 20:04, David Smith via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> +1.  This is my favorite solution so far. 
>>> 
>>> With ‘Person.keypath.name' it is obvious that we are creating a key path.  
>>> There is no ambiguity for the reader.  With autocomplete it will be very 
>>> little extra typing anyway…
>> 
>> But that adds a lot of verbosity. They disregarded #keyPath because it was 
>> too verbose.
> 
> For what it's worth, I'm not especially worried about verbosity. Long-term 
> I'm hoping that this feature and the ones we build on it will see far broader 
> use than keypaths ever did in ObjC, but a little more typing isn't that bad. 
> What *is* a loss though, is something I'll call "conceptual surface area".
> 
> We talk a lot about "conceptual load" when designing APIs, which is the 
> notion that even if each individual concept is simple, the sheer volume of 
> things that you have to keep track of can be exhausting, make learning 
> difficult, and cause mistakes. With some features though, the conceptual load 
> comes more from what isn't there. With unbound methods, you have to know "ok 
> String.init gets me String's initializer as an unbound function I can call, 
> so I can do stuff like [1, 2, 3].map(String.init)" but you *also* have to 
> know "but that doesn't work on subscripts or properties, just methods". So 
> even though there's only one concept here, the hole in the feature is itself 
> an additional concept; an irregularly shaped thing having more mental surface 
> area.
> 
> So the biggest reason I like the current syntax proposal is that it fills in 
> a hole, reducing the conceptual surface area to "ok, Foo.bar gets me an 
> unbound version of anything".
> 
> Unfortunately, as everyone has pointed out, static/class properties make that 
> claim not so true. Hanging keypaths off a ".keypath" class property also 
> conflicts, since there's nothing stopping a method or property from being 
> called "keypath". I see several paths forward from here, not least of which 
> is "it's probably not a huge deal in practice", but I'd like to think about 
> it and listen to the discussion a bit longer before suggesting anything.

Would an operator solve this issue? I have to admit I've never really used 
something like this so I've only really been half-glancing at this thread as 
the messages come up, but it seems like an operator would keep the paths from 
being too verbose, while disambiguating.

This may in fact be something where the dollar sign could be a good fit, i.e: 
$Foo.bar

It's unambiguous with shorthand variables in closures, and keeps the feature in 
the same kind of "sort of compiler magic" category that they exist in, since 
they're not proper variables, but can be used as such, just as a key-path here 
is sort of a property access, but handled in a special way.

Just a thought anyway.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 22:49, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> That’s why protected (a feature) is on the commonly rejected proposals list
> 
> 
> Unless you’re referring to a different “commonly rejected proposals” list 
> than the one below, this does not appear to be true:
> 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> 

Perceptions and sometimes... wishful thinking ;).

> Charles
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution 
>  wrote:
> 
> That’s why protected (a feature) is on the commonly rejected proposals list


Unless you’re referring to a different “commonly rejected proposals” list than 
the one below, this does not appear to be true:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 


Charles

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

> On 21 Mar 2017, at 21:59, Drew Crawford  wrote:
> 
>>  The arguments for the revert are in the proposal and in the discussions in 
>> this thread.
> 
> 
> What is in the proposal and this thread are a set of opinions, e.g.
> 
> * "the access level change of SE-0025 was met with dissatisfaction by a 
> substantial proportion of the general Swift community."
> * "Those changes can be viewed as actively harmful,”
> * "it is extremely common to use several extensions within a file.”
> * “[existing regime] encourages overuse of scoped access control”
> * “[fileprivate is the] more reasonable default”
> 
> I am asking for the arguments or evidence that led you or others to these 
> opinions.  I understand that you and others believe them, but you understand 
> that they are now a matter of debate. We are not going to reach any mutual 
> understanding just asserting things we believe.  The underlying evidence is 
> what would be necessary to convince others to our point of view.  I am trying 
> to ascertain what that evidence is.
> 
>> > It has pointed quite a few times by core team members that comparison to 
>> > languages is not a very strong arguments, 
> 
> 
> The context here is that you presented an argument that Swift’s “private” was 
> confusing to users of other languages:
> 
> > In most languages, that keyword is “private” so its valid to say that 
> > newcomers to the language will “default” to using that one. 
> 
> If you no longer think that argument is strong because it relies on a 
> comparison to other languages, then we agree :-)  But in that case we lose an 
> argument for this proposal.  The reason we are talking about other languages 
> is because that was an argument advanced to support the proposal.

Excuse me, I did not express my point well. What I meant is that wanting a 
feature in Swift because it exists in another language has not been a very 
strong argument. But contrarily, making Swift familiar to users of other 
languages because it uses similar concepts or keywords is a different story. 
That’s why protected (a feature) is on the commonly rejected proposals list, 
because it doesn’t fit with Swift even though it exists in other languages. 
But, on the other hand, keywords like try/throws (syntax) have been used 
despite the fact that Swift doesn’t have exceptions specifically to feel 
familiar to newcomers.

In that regard, wanted the scoped-private private (feature) in Swift because 
other languages have it, seems to me like a weaker argument than the argument 
that the private keyword (syntax) brings familiarity.

>> > Some people used the for(;;) loop, the ++ operator, var parameters.
> 
> 
> In those cases, there was extensive discussion of how to achieve the things 
> people were achieving with those features with alternative patterns. var 
> parameters for example have a 1LOC workaround to achieve the previous 
> semantics, ++ had two characters, for(;;) was slightly trickier but we had a 
> clear concept of the scope of the impact. So far as I’m aware, the only 
> suggestion to people who currently use a scoped access modifier is to stop 
> having their problems. So the circumstances of earlier removals and this one 
> are very different.
> 
>> > • either a programmer ... will use private as often as possible
>> > • or a programmer will … use fileprivate all the time 
> 
> There is also the possibility that a programmer considers which modifier is 
> appropriate for the code they are writing.  You "argue that... is very rare” 
> but I still am not sure what this argument is or what led you or others to 
> this conclusion.
> 
> On March 21, 2017 at 1:41:48 PM, David Hart (da...@hartbit.com 
> ) wrote:
> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On 21 Mar 2017, at 16:57, Drew Crawford > > wrote:
>> 
>>> 
>>> 
 > I’m not arguing that it is less or more than a majority. I’m just saying 
 > that we’ve seen a lot of talk against the original change.
>>> 
>>> This proposal asks us to balance the convenience of one group 
>>> (extension-writers) against the existence of another (scoped-access users). 
>>>  To do that, we need a clear idea of the composition of both groups.
>>> 
>>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>>> was not good enough when we introduced the feature, that required argument 
>>> and clear use-cases.
>>> 
>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>> warning that something may be very controversial among the community. The 
>> arguments for the revert are in the proposal and in the discussions in this 
>> thread.
>> 
 > By default, I did not mean the syntactic default of the language but the 
 > access modifier users will use “by default” when trying to restrict 
 > visibility. In most languages, that keyword is “private” so its valid to 
 > say that 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>  The arguments for the revert are in the proposal and in the discussions
> in this thread.
>
>
> What is in the proposal and this thread are a set of opinions, e.g.
>
> * "the access level change of SE-0025 was met with dissatisfaction by a
> substantial proportion of the general Swift community."
> * "Those changes can be viewed as actively harmful,”
> * "it is extremely common to use several extensions within a file.”
> * “[existing regime] encourages overuse of scoped access control”
> * “[fileprivate is the] more reasonable default”
>
> I am asking for the arguments or evidence that led you or others to these
> opinions.  I understand that you and others believe them, but you
> understand that they are now a matter of debate. We are not going to reach
> any mutual understanding just asserting things we believe.  The underlying
> evidence is what would be necessary to convince others to our point of
> view.  I am trying to ascertain what that evidence is.
>
> > It has pointed quite a few times by core team members that comparison to
> languages is not a very strong arguments,
>
>
> The context here is that you presented an argument that Swift’s “private”
> was confusing to users of other languages:
>
> > In most languages, that keyword is “private” so its valid to say that
> newcomers to the language will “default” to using that one.
>
> If you no longer think that argument is strong because it relies on a
> comparison to other languages, then we agree :-)  But in that case we lose
> an argument for this proposal.  The reason we are talking about other
> languages is because that was an argument advanced to support the proposal.
>
>
I am confused by this response. An argument in _support_ of new `private`
was that it is more in line with expectations of users coming from other
languages. In other some cases, such an argument might have its place.
However, as others have pointed out on this list, those other languages
don't have facilities like Swift's extensions, and therefore it was not a
very strong argument for new `private` to say that it better aligns with
user expectations coming from other languages.


> > Some people used the for(;;) loop, the ++ operator, var parameters.
>
>
> In those cases, there was extensive discussion of how to achieve the
> things people were achieving with those features with alternative patterns.
> var parameters for example have a 1LOC workaround to achieve the previous
> semantics, ++ had two characters, for(;;) was slightly trickier but we had
> a clear concept of the scope of the impact. So far as I’m aware, the only
> suggestion to people who currently use a scoped access modifier is to stop
> having their problems.
>

You've given one example of code that takes advantage of new `private`. As
far as I can see, in that example, you can rename `private func prune` to
`private func _prune` and have no further problems. That is to say, the
workaround is a single character at each use site, which by your metric
makes this proposal half as onerous as removing `++`.

So the circumstances of earlier removals and this one are very different.
>
> > • either a programmer ... will use private as often as possible
> > • or a programmer will … use fileprivate all the time
>
> There is also the possibility that a programmer considers which modifier
> is appropriate for the code they are writing.  You "argue that... is very
> rare” but I still am not sure what this argument is or what led you or
> others to this conclusion.
>

I'm not enamored of the argumentation in the proposal set out above. But
since you are saying that you're not sure how anybody came to support this
proposal, here's how I arrived at supporting it:

A core team member (I'm blanking on who) has pointed out that, in the end,
the only necessary access modifiers are public and not public (spelled
"internal" in Swift). It has been my understanding that supporting all
possible ways of hiding a member from arbitrary other code within the same
module is a _non-goal_. There have been numerous attempts at designing
elaborate access modifier schemes that make this possible with friends,
protected, shared, what-have-you, and I try to bring up this point each
time.

Beyond the two absolutely essential access modifiers, anything else does
not add to safety as the term is understood in Swift, but rather improves
developer experience. But what is gained in terms of developer experience
with each additional access modifier (due to increased expressiveness) is
offset by what is lost due to complexity. So then the question is: what is
the ideal number of access modifiers? is it two? three? four? five? six?
eight? ten? twelve?

When new `private` and `fileprivate` were shipped, there were numerous
questions asked by users on forums such as Stack Overflow (easily googled;
just as a single example:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On Mar 21, 2017, at 4:48 PM, Jose Cheyo Jimenez  wrote:
> 
> 
>>> On Mar 21, 2017, at 2:33 PM, Matthew Johnson  wrote:
>>> 
>>> 
 On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez  
 wrote:
 
 
> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just 
>>> > saying that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access 
>> users).  To do that, we need a clear idea of the composition of both 
>> groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>> was not good enough when we introduced the feature, that required 
>> argument and clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in 
> this thread.
> 
>>> > By default, I did not mean the syntactic default of the language but 
>>> > the access modifier users will use “by default” when trying to 
>>> > restrict visibility. In most languages, that keyword is “private” so 
>>> > its valid to say that newcomers to the language will “default” to 
>>> > using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed 
>> restricted the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is 
>> file-visible?  It isn’t Java, C++, or PHP.  C#’s “partial” is the 
>> closest I can think of, and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does 
> things differently for a good reason. I can't stop from quoting Xiaodi 
> from a month back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 
>> A user who wants a middle-ground visibility would “default” to 
>> “protected”, “friend”, “partial”, or similar.  After that does not 
>> compile, they will use google to find a middle-road visibility keyword, 
>> for which the only candidate is “fileprivate”.  But they will not choose 
>> “private”, it’s just not a reasonable expectation of what the keyword 
>> means to a new Swift developer.
>> 
>> The popularity of private “as a default” is simply because many users 
>> prefer to hide their implementation details as a matter of routine code 
>> hygiene.  Redefining private in order to thwart their code hygiene goal 
>> seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use 
> private as often as possible and relegate to fileprivate when the design 
> leaves no other choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate 
> all the time and the language feels like it has an unnecessary access 
> modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is 
> very rare. As a consequence, we should try to only keep one. Removing 
> fileprivate is a no-go with extensions so that leaves us with removing 
> private.
 
 Removing scoped access is a no-go if we consider tightly encapsulating 
 invariant-preserving state to be an important feature.  The fact is that 
 both features can be used meaningfully.  The fact that some people choose 
 not to do this is not an argument against the features being available.  
 It is an opportunity to encourage people to thing more carefully about why 
 they are encapsulating something.  
>>> 
>>> I understand the bigger picture you are getting at but the scope access you 
>>> have envisioned should not 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 2:33 PM, Matthew Johnson  wrote:
> 
>> 
>> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
 > wrote:
 
 
 
 
 
 Sent from my iPhone
 On 21 Mar 2017, at 16:57, Drew Crawford > wrote:
 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just 
>> > saying that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access 
> users).  To do that, we need a clear idea of the composition of both 
> groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
> was not good enough when we introduced the feature, that required 
> argument and clear use-cases.
> 
 "A lot of talk" is not the evidence supporting the proposal: it's just a 
 warning that something may be very controversial among the community. The 
 arguments for the revert are in the proposal and in the discussions in 
 this thread.
 
>> > By default, I did not mean the syntactic default of the language but 
>> > the access modifier users will use “by default” when trying to 
>> > restrict visibility. In most languages, that keyword is “private” so 
>> > its valid to say that newcomers to the language will “default” to 
>> > using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted 
> the visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible? 
>  It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think 
> of, and it isn’t at all close.
 
 It has pointed quite a few times by core team members that comparison to 
 languages is not a very strong arguments, especially when Swift does 
 things differently for a good reason. I can't stop from quoting Xiaodi 
 from a month back:
 
 «The beauty of Swift 2's access modifiers was that they were based around 
 files and modules, explicitly rejecting types and scopes as units for 
 determining visibility.» -- Xiaodi
 
> A user who wants a middle-ground visibility would “default” to 
> “protected”, “friend”, “partial”, or similar.  After that does not 
> compile, they will use google to find a middle-road visibility keyword, 
> for which the only candidate is “fileprivate”.  But they will not choose 
> “private”, it’s just not a reasonable expectation of what the keyword 
> means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users 
> prefer to hide their implementation details as a matter of routine code 
> hygiene.  Redefining private in order to thwart their code hygiene goal 
> seems extreme.
 
 The point is that keeping both private and fileprivate feels like an 
 un-necessary complication:
 
 • either a programmer falls on your side of the fence and will use private 
 as often as possible and relegate to fileprivate when the design leaves no 
 other choice. At that point it feels like a language wart.
 • or a programmer will fall on my side of the fence and use fileprivate 
 all the time and the language feels like it has an unnecessary access 
 modifier.
 
 I'd argue that the cases when a programmer will use both meaningfully is 
 very rare. As a consequence, we should try to only keep one. Removing 
 fileprivate is a no-go with extensions so that leaves us with removing 
 private.
>>> 
>>> Removing scoped access is a no-go if we consider tightly encapsulating 
>>> invariant-preserving state to be an important feature.  The fact is that 
>>> both features can be used meaningfully.  The fact that some people choose 
>>> not to do this is not an argument against the features being available.  It 
>>> is an opportunity to encourage people to thing more carefully about why 
>>> they are encapsulating something.  
>> 
>> I understand the bigger picture you are getting at but the scope access you 
>> have envisioned should not be called private. 
> 
> I don’t disagree with this.  I’m fine with renaming it 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez  wrote:
> 
> 
>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On 21 Mar 2017, at 16:57, Drew Crawford >> > wrote:
>>> 
 
 
> > I’m not arguing that it is less or more than a majority. I’m just 
> > saying that we’ve seen a lot of talk against the original change.
 
 This proposal asks us to balance the convenience of one group 
 (extension-writers) against the existence of another (scoped-access 
 users).  To do that, we need a clear idea of the composition of both 
 groups.
 
 “A lot of talk” is not the evidentiary standard to remove a feature.  It 
 was not good enough when we introduced the feature, that required argument 
 and clear use-cases.
 
>>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>>> warning that something may be very controversial among the community. The 
>>> arguments for the revert are in the proposal and in the discussions in this 
>>> thread.
>>> 
> > By default, I did not mean the syntactic default of the language but 
> > the access modifier users will use “by default” when trying to restrict 
> > visibility. In most languages, that keyword is “private” so its valid 
> > to say that newcomers to the language will “default” to using that one.
 
 Apologies, but I do not understand the argument:
 
 A user wants to restrict visibility (e.g. they are dissatisfied with 
 “internal”)
 The user *chooses* private because of familiarity from another language
 The user is then surprised that their choice of private indeed restricted 
 the visibility, thus achieving their goal?
 What language does the user come from in which “private” is file-visible?  
 It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
 and it isn’t at all close.
>>> 
>>> It has pointed quite a few times by core team members that comparison to 
>>> languages is not a very strong arguments, especially when Swift does things 
>>> differently for a good reason. I can't stop from quoting Xiaodi from a 
>>> month back:
>>> 
>>> «The beauty of Swift 2's access modifiers was that they were based around 
>>> files and modules, explicitly rejecting types and scopes as units for 
>>> determining visibility.» -- Xiaodi
>>> 
 A user who wants a middle-ground visibility would “default” to 
 “protected”, “friend”, “partial”, or similar.  After that does not 
 compile, they will use google to find a middle-road visibility keyword, 
 for which the only candidate is “fileprivate”.  But they will not choose 
 “private”, it’s just not a reasonable expectation of what the keyword 
 means to a new Swift developer.
 
 The popularity of private “as a default” is simply because many users 
 prefer to hide their implementation details as a matter of routine code 
 hygiene.  Redefining private in order to thwart their code hygiene goal 
 seems extreme.
>>> 
>>> The point is that keeping both private and fileprivate feels like an 
>>> un-necessary complication:
>>> 
>>> • either a programmer falls on your side of the fence and will use private 
>>> as often as possible and relegate to fileprivate when the design leaves no 
>>> other choice. At that point it feels like a language wart.
>>> • or a programmer will fall on my side of the fence and use fileprivate all 
>>> the time and the language feels like it has an unnecessary access modifier.
>>> 
>>> I'd argue that the cases when a programmer will use both meaningfully is 
>>> very rare. As a consequence, we should try to only keep one. Removing 
>>> fileprivate is a no-go with extensions so that leaves us with removing 
>>> private.
>> 
>> Removing scoped access is a no-go if we consider tightly encapsulating 
>> invariant-preserving state to be an important feature.  The fact is that 
>> both features can be used meaningfully.  The fact that some people choose 
>> not to do this is not an argument against the features being available.  It 
>> is an opportunity to encourage people to thing more carefully about why they 
>> are encapsulating something.  
> 
> I understand the bigger picture you are getting at but the scope access you 
> have envisioned should not be called private. 

I don’t disagree with this.  I’m fine with renaming it and allowing `private` 
to mean file-level scope.

> 
> In order to get scope access to a place where it is more useful we have to 
> remove it.

No we don’t.  We could remove it and re-add it but that would be crazy.  We 
would break a 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On 21 Mar 2017, at 16:57, Drew Crawford > > wrote:
>> 
>>> 
>>> 
 > I’m not arguing that it is less or more than a majority. I’m just saying 
 > that we’ve seen a lot of talk against the original change.
>>> 
>>> This proposal asks us to balance the convenience of one group 
>>> (extension-writers) against the existence of another (scoped-access users). 
>>>  To do that, we need a clear idea of the composition of both groups.
>>> 
>>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>>> was not good enough when we introduced the feature, that required argument 
>>> and clear use-cases.
>>> 
>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>> warning that something may be very controversial among the community. The 
>> arguments for the revert are in the proposal and in the discussions in this 
>> thread.
>> 
 > By default, I did not mean the syntactic default of the language but the 
 > access modifier users will use “by default” when trying to restrict 
 > visibility. In most languages, that keyword is “private” so its valid to 
 > say that newcomers to the language will “default” to using that one.
>>> 
>>> Apologies, but I do not understand the argument:
>>> 
>>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>>> “internal”)
>>> The user *chooses* private because of familiarity from another language
>>> The user is then surprised that their choice of private indeed restricted 
>>> the visibility, thus achieving their goal?
>>> What language does the user come from in which “private” is file-visible?  
>>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>>> and it isn’t at all close.
>> 
>> It has pointed quite a few times by core team members that comparison to 
>> languages is not a very strong arguments, especially when Swift does things 
>> differently for a good reason. I can't stop from quoting Xiaodi from a month 
>> back:
>> 
>> «The beauty of Swift 2's access modifiers was that they were based around 
>> files and modules, explicitly rejecting types and scopes as units for 
>> determining visibility.» -- Xiaodi
>> 
>>> A user who wants a middle-ground visibility would “default” to “protected”, 
>>> “friend”, “partial”, or similar.  After that does not compile, they will 
>>> use google to find a middle-road visibility keyword, for which the only 
>>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>>> not a reasonable expectation of what the keyword means to a new Swift 
>>> developer.
>>> 
>>> The popularity of private “as a default” is simply because many users 
>>> prefer to hide their implementation details as a matter of routine code 
>>> hygiene.  Redefining private in order to thwart their code hygiene goal 
>>> seems extreme.
>> 
>> The point is that keeping both private and fileprivate feels like an 
>> un-necessary complication:
>> 
>> • either a programmer falls on your side of the fence and will use private 
>> as often as possible and relegate to fileprivate when the design leaves no 
>> other choice. At that point it feels like a language wart.
>> • or a programmer will fall on my side of the fence and use fileprivate all 
>> the time and the language feels like it has an unnecessary access modifier.
>> 
>> I'd argue that the cases when a programmer will use both meaningfully is 
>> very rare. As a consequence, we should try to only keep one. Removing 
>> fileprivate is a no-go with extensions so that leaves us with removing 
>> private.
> 
> Removing scoped access is a no-go if we consider tightly encapsulating 
> invariant-preserving state to be an important feature.  The fact is that both 
> features can be used meaningfully.  The fact that some people choose not to 
> do this is not an argument against the features being available.  It is an 
> opportunity to encourage people to thing more carefully about why they are 
> encapsulating something.  

I understand the bigger picture you are getting at but the scope access you 
have envisioned should not be called private. 

In order to get scope access to a place where it is more useful we have to 
remove it.

I don’t mind if scope access is kept but it must have a different name and that 
should be a different limited scope proposal. 

Opposing SE-0159 will make it much harder to redefine scope access.


> 
> A programmer has to make a conscious decision to give a declaration 
> visibility other than internal.  If they have trouble identifying whether 
> file or scoped access is appropriate this indicates they don’t really 
> 

Re: [swift-evolution] [Proposal] Factory Initializers

[Jonathan Hull via swift-evolution]

There are several reasons.  It is a very common pattern in ObjC/Cocoa.  For 
example, they allow class clusters (and the protocol equivalent).

One of the Apple foundation people replied earlier in this thread that it would 
allow them to remove several hacks from the foundation overlays, and improve 
safety.

One of the ideas I am most excited about is the ability for a protocol to 
provide default conformances.  For example, I have an Expression protocol to 
represent mathematical expressions, and I have a few basic conforming structs 
representing constants, variables, and some basic operations.  With a factory 
method, I can say ‘Expression(2)’ or ‘Expression(“VarName”)’ and have it create 
the correct conformance.  My conforming structs can even be private, if I want 
this to be the only way they are created.

If I have expensive-to-create immutable objects where I am creating equivalent 
values all the time, I can store commonly created values in a cache and return 
the cached versions (instead of creating an instance).  I believe cocoa used to 
do this with NSNumbers before tagged pointers became a thing.

Or, I could return something which is lazily created.

Longer term (once reflection has improved), I have a proposal to allow 
extensible factory methods. We talked about it during the original discussion, 
but the gist is that there would be way to get a list of all types conforming 
to a protocol (or all subclasses of a class) from the compiler, and then you 
could use static methods to query those types until you found one which has the 
properties you are looking for, and then instantiate and return it.  The end 
result is that you have a factory initializer where new conformances (even from 
plug-ins) can participate and be returned when appropriate.  This proposal is a 
necessary first step to that.

As a concrete use-case of that extension, I have been experimenting for years 
with auto-creating UI to edit structured data (e.g. JSON or Plists) or objects. 
 This is fairly easy in ObjC, but it is only possible in Swift in a very 
limited way at the moment.  With the above extension and key paths, I should be 
able to recreate my ObjC interfaces in a nicer/swiftier way.

Those are just a few of the uses.

Thanks,
Jon

> On Mar 21, 2017, at 8:49 AM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> Forgive me if that has already been discussed in the email threads prior to 
> the proposal, but what I’m missing from this proposal is a discussion of the 
> problems factory initializers solve (other than the examples at the end) and 
> an explanation of why factory initializers are the right solution to 
> that/those problems in Swift.
> 
> I acknowledge that it’s a common pattern in many languages, but don’t find it 
> a very strong argument as to why it should be built into the language. 
>  
> Regards,
> David
> 
> 
>> On 17 Mar 2017, at 17:26, Riley Testut via swift-evolution 
>> > wrote:
>> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 > wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

 The arguments for the revert are in the proposal and in the discussions in 
this thread.

What is in the proposal and this thread are a set of opinions, e.g.

* "the access level change of SE-0025 was met with dissatisfaction by a 
substantial proportion of the general Swift community."
* "Those changes can be viewed as actively harmful,”
* "it is extremely common to use several extensions within a file.”
* “[existing regime] encourages overuse of scoped access control”
* “[fileprivate is the] more reasonable default”

I am asking for the arguments or evidence that led you or others to these 
opinions.  I understand that you and others believe them, but you understand 
that they are now a matter of debate. We are not going to reach any mutual 
understanding just asserting things we believe.  The underlying evidence is 
what would be necessary to convince others to our point of view.  I am trying 
to ascertain what that evidence is.

> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, 

The context here is that you presented an argument that Swift’s “private” was 
confusing to users of other languages:

> In most languages, that keyword is “private” so its valid to say that 
> newcomers to the language will “default” to using that one. 

If you no longer think that argument is strong because it relies on a 
comparison to other languages, then we agree :-)  But in that case we lose an 
argument for this proposal.  The reason we are talking about other languages is 
because that was an argument advanced to support the proposal.

> Some people used the for(;;) loop, the ++ operator, var parameters.

In those cases, there was extensive discussion of how to achieve the things 
people were achieving with those features with alternative patterns. var 
parameters for example have a 1LOC workaround to achieve the previous 
semantics, ++ had two characters, for(;;) was slightly trickier but we had a 
clear concept of the scope of the impact. So far as I’m aware, the only 
suggestion to people who currently use a scoped access modifier is to stop 
having their problems. So the circumstances of earlier removals and this one 
are very different.

> • either a programmer ... will use private as often as possible
> • or a programmer will … use fileprivate all the time 
There is also the possibility that a programmer considers which modifier is 
appropriate for the code they are writing.  You "argue that... is very rare” 
but I still am not sure what this argument is or what led you or others to this 
conclusion.

On March 21, 2017 at 1:41:48 PM, David Hart (da...@hartbit.com) wrote:





Sent from my iPhone
On 21 Mar 2017, at 16:57, Drew Crawford  wrote:



> I’m not arguing that it is less or more than a majority. I’m just saying that 
> we’ve seen a lot of talk against the original change.
This proposal asks us to balance the convenience of one group 
(extension-writers) against the existence of another (scoped-access users).  To 
do that, we need a clear idea of the composition of both groups.

“A lot of talk” is not the evidentiary standard to remove a feature.  It was 
not good enough when we introduced the feature, that required argument and 
clear use-cases.

"A lot of talk" is not the evidence supporting the proposal: it's just a 
warning that something may be very controversial among the community. The 
arguments for the revert are in the proposal and in the discussions in this 
thread.

> By default, I did not mean the syntactic default of the language but the 
> access modifier users will use “by default” when trying to restrict 
> visibility. In most languages, that keyword is “private” so its valid to say 
> that newcomers to the language will “default” to using that one.
Apologies, but I do not understand the argument:

A user wants to restrict visibility (e.g. they are dissatisfied with “internal”)
The user *chooses* private because of familiarity from another language
The user is then surprised that their choice of private indeed restricted the 
visibility, thus achieving their goal?
What language does the user come from in which “private” is file-visible?  It 
isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and it 
isn’t at all close.

It has pointed quite a few times by core team members that comparison to 
languages is not a very strong arguments, especially when Swift does things 
differently for a good reason. I can't stop from quoting Xiaodi from a month 
back:

«The beauty of Swift 2's access modifiers was that they were based around files 
and modules, explicitly rejecting types and scopes as units for determining 
visibility.» -- Xiaodi

A user who wants a middle-ground visibility would “default” to “protected”, 
“friend”, “partial”, or similar.  After that does not compile, they will use 
google to find a middle-road visibility keyword, for which the only candidate 
is 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 18:41, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>>> > that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access users).  
>> To do that, we need a clear idea of the composition of both groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
>> not good enough when we introduced the feature, that required argument and 
>> clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in this 
> thread.
> 
>>> > By default, I did not mean the syntactic default of the language but the 
>>> > access modifier users will use “by default” when trying to restrict 
>>> > visibility. In most languages, that keyword is “private” so its valid to 
>>> > say that newcomers to the language will “default” to using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed restricted 
>> the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is file-visible?  
>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>> and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does things 
> differently for a good reason. I can't stop from quoting Xiaodi from a month 
> back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 

I do not see how Swift explicitly rejected both types and scope for determining 
visibility, we have private and fileprivate for a reason and they may not help 
everybody to feel Swifty or whatever that means in practice, but it allows 
others to do actual work. Having additional flexibility does not hurt people 
that want to stick with file based visibility.

None of us here is paid to write haiku/poetry code, so while beauty has a place 
it is not the necessary and sufficient condition for language features: code is 
meant to be read, refactored, and most of all shipped and debugged quickly.

>> A user who wants a middle-ground visibility would “default” to “protected”, 
>> “friend”, “partial”, or similar.  After that does not compile, they will use 
>> google to find a middle-road visibility keyword, for which the only 
>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>> not a reasonable expectation of what the keyword means to a new Swift 
>> developer.
>> 
>> The popularity of private “as a default” is simply because many users prefer 
>> to hide their implementation details as a matter of routine code hygiene.  
>> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use private as 
> often as possible and relegate to fileprivate when the design leaves no other 
> choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate all 
> the time and the language feels like it has an unnecessary access modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is very 
> rare. As a consequence, we should try to only keep one. Removing fileprivate 
> is a no-go with extensions so that leaves us with removing private.
> 
>> I agree with several here (as I did in SE-0025) that our access modifiers 
>> are not well-named.  However, that’s not the proposal in front of us.
>> 
>>> > My own statistics in my projects show the contrary. At best, this shows 
>>> > how divisive this feature is.
>> 
>> This *may* show that, if contrary statistics were presented, but that hasn’t 
>> occurred.
>> 
> I can generate statistics from my projects if you want. But it's unnecessary: 
> I haven't used private once since it's introduction in Swift 3. I don't see 
> the advantages it brings worth the trouble.
>>> In old code, statistics could be biased by the migrator having replaced all 
>>> previous instances of private by 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 15:57, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.
> 

I agree, the old change gave private a much more commonly understood and IMHO 
more understandable meaning (changing do while into repeat while is the kind of 
change I would not like to see again unless well justified :)).

> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
> Swift 3 shipped, so what we are discussing now is yanking a keyword without 
> replacement.  There is code written that uses private to enforce its 
> threading or security invariants.  There is code written that uses private in 
> order to shadow another declaration.   There is code that will not compile 
> after migration. We need more than a vague fear of complexity generally to 
> throw a brick through all those windows.  That brick will introduce quite a 
> bit of complexity itself.
> 
>> Concerning the one-class-per-file argument, I would suggest this 
>> counter-argument: when working in large projects, I believe it's a good 
>> thing if the language encourages (forces is too strong a word for my taste) 
>> a one class per file structure, it's good practice.
> 
> The form of the argument is invalid.  Suppose I argued: "it’s a good thing 
> for the language to encourage one definition per class (no extensions), it’s 
> good practice.  So we do not need fileprivate.”  That would be very silly 
> (although it has already been advanced as a straw-man position elsewhere in 
> this thread). The argument that we do not need private because nobody should 
> put multiple classes in a file is equally silly. There are reasons to do so, 
> in fact one motivation was given in SE-0025:
> 
>> > Putting related APIs and/or related implementations in the same file helps 
>> > ensure consistency and reduces the time to find a particular API or 
>> > implementation. 
> 
> 
> These concerns are not resolved by arguments of the form “just don’t do that”.

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 20:36, Goffredo Marocchi  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 16:23, Davor Jankolija via swift-evolution 
>>  wrote:
>> 
>> 
>>> What is your evaluation of the proposal?
>> 
>> + 1.
>> 
>> Don’t like to admit it but i favored the fileprivate modifier when it was 
>> introduced. Alas more experince with Swift has meant that I now very often 
>> catch myself changing private to fileprivate if for nothing else then to 
>> allow protocol conformance through extensions in the same file. Even though 
>> this may not be a good enough reason to make me go with supporting the 
>> proposal, the fact that access modifiers are fundamental to most modern PLs 
>> and fileprivate vs private as is is now adds too little while on the other 
>> hand adds another access modifier which IMHO should be simple and allow 
>> encapsluation (as some have said, internal and public are actually enough to 
>> achieve this) means for me this is something worth reverting.
> 
> The current situation does not prevent anyone from expressing 
> themselves/implementing their preferred patterns. I am really not sure why we 
> should revert a change which allowed people that value and need scope based 
> access to do their job?
> 
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> Yes.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Most other languages encapsulate based on type and inheritance, so this 
>> strays a bit by making private extend beyond the class definition itself. 
>> However, no other language I’ve used make use of extensions the way Swift 
>> does so it makes sense in a Swift environment.
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Followed both the original conversation added fileprivate as well as the 
>> other conversations which led to this proposal. 
>> 
>> - Davor
>> 
>> ___
>> 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] Smart KeyPaths

[David Smith via swift-evolution]

> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>  wrote:
>> 
>> +1.  This is my favorite solution so far. 
>> 
>> With ‘Person.keypath.name' it is obvious that we are creating a key path.  
>> There is no ambiguity for the reader.  With autocomplete it will be very 
>> little extra typing anyway…
> 
> But that adds a lot of verbosity. They disregarded #keyPath because it was 
> too verbose.

For what it's worth, I'm not especially worried about verbosity. Long-term I'm 
hoping that this feature and the ones we build on it will see far broader use 
than keypaths ever did in ObjC, but a little more typing isn't that bad. What 
*is* a loss though, is something I'll call "conceptual surface area".

We talk a lot about "conceptual load" when designing APIs, which is the notion 
that even if each individual concept is simple, the sheer volume of things that 
you have to keep track of can be exhausting, make learning difficult, and cause 
mistakes. With some features though, the conceptual load comes more from what 
isn't there. With unbound methods, you have to know "ok String.init gets me 
String's initializer as an unbound function I can call, so I can do stuff like 
[1, 2, 3].map(String.init)" but you *also* have to know "but that doesn't work 
on subscripts or properties, just methods". So even though there's only one 
concept here, the hole in the feature is itself an additional concept; an 
irregularly shaped thing having more mental surface area.

So the biggest reason I like the current syntax proposal is that it fills in a 
hole, reducing the conceptual surface area to "ok, Foo.bar gets me an unbound 
version of anything".

Unfortunately, as everyone has pointed out, static/class properties make that 
claim not so true. Hanging keypaths off a ".keypath" class property also 
conflicts, since there's nothing stopping a method or property from being 
called "keypath". I see several paths forward from here, not least of which is 
"it's probably not a huge deal in practice", but I'd like to think about it and 
listen to the discussion a bit longer before suggesting anything.

David

> 
>> Thanks,
>> Jon
>> 
>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution 
>>>  wrote:
>>> 
>>> Key paths of this form:
>>> 
>>> Person.name
>>> 
>>> will always make it harder than necessary to:
>>> 
>>> * search for all places where we are using key paths
>>> 
>>> * do efficient code completion. Eg you’ll get a mix of static properties 
>>> and key paths
>>> 
>>> 
>>> We’ve been using this kind of setup in our projects for some time now:
>>> 
>>> class Person {
>>> 
>>> struct keypath {
>>> 
>>>static let name = #keyPath(Person.name)
>>>…
>>> }
>>> 
>>> …
>>> }
>>> 
>>> where a keypath is then used like this:
>>> 
>>> Person.keypath.name
>>> 
>>> and this has worked very well. It makes it easy to see where we are using a 
>>> keypath rather than accessing some static property, it works very nicely 
>>> with code completion and it makes it very easy to search for all places 
>>> where we are using key paths from the Person type.
>>> 
>>> I would prefer that the proposed keypath model would automatically organize 
>>> key paths like this.
>>> 
>>> 
>>> Regards,
>>> 
>>> Dietmar Planitzer
>>> 
>>> 
 On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution 
  wrote:
 
 
 
 Sent from my iPad
 
> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> I think the clarity desired is more similar to that obtained by the `try` 
> keyword. Ya, the compiler knows that this function throws already, but 
> Swift aims for clarity in the source code. Clarity is often achieved by 
> providing potentially redundant information for the programmer.
> 
> As proposed, it is difficult to distinguish a key path from a static 
> variable. Maybe that's not problematic? Well, it's up to the community to 
> decide.
 
 Why don't we just say all instance properties are shadowed by a static 
 constant property of the same name with the appropriate key path type.  
 This makes it not mysterious at all but instead very straightforward.  We 
 could even say that static and class properties are shadowed by a key path 
 property on the meta type.
 
 
> I do think it is a bit worrisome that static variable access might cause 
> side effects (or at least, might take a while to compute) but creating 
> key paths should not, but that's a fringe case probably.
> 
> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Michel Fortin via swift-evolution]

>   • What is your evaluation of the proposal?

Renaming `fileprivate` to `private` makes sense. In my code, I use 
`fileprivate` and `private` interchangeably, meaning that I write `private` for 
things that shouldn't be leaked to the whole module and if by chance the 
compiler complain I'll change it to `fileprivate` without a second thought. 
This tells me that I'm using the feature wrong: I should be writing 
`fileprivate` everywhere and narrowing it to `private` only where it is really 
important that I do so. But a name like `fileprivate` makes this rather 
difficult.

So I'd be glad to see that problem go away.


>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

I think it is significant enough. I think the core team's evaluation for Swift 
3 that `fileprivate` would be rarely used was completely mistaken. Worse, 
forcing the use of the dirtier word `fileprivate` is draining all thoughtful 
intent from `private` in Swift 3. It's not a good thing when `private` is used 
only because it compiles and changed to `fileprivate` on a whim whenever the 
compiler complains.

While I don't have much attachment to the scoped-private concept, I'm not 
convinced its total removal is necessary either. Alternative 3 might solve this 
problem with less disruption to the language. While it offers some room to 
replicate the same problem I described above -- with different keywords -- I 
feel using a word like `scoped` would be less prone to overuse than `private` 
and therefore more truthful to the actual intent. If so, that would fix the 
problem too.

Either way, something must be done.


>   • Does this proposal fit well with the feel and direction of Swift?

I think it does. The conflation of `private` and `fileprivate` at the top level 
of the file always sounded indicative to me of a flaw in the design. Correcting 
this would be an improvement.


>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I'm used to D where `private` has the pretty much same meaning as `fileprivate` 
in Swift. I never found that much of a problem. But I've seen similar debates 
there too.


>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've read the proposal and most of the discussion, even though I haven't 
participated much.


-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Colin Barrett via swift-evolution]

Hi Itai,

On Tue, Mar 21, 2017 at 1:03 PM Itai Ferber  wrote:

Hi Colin,

Thanks for your comments! Are you talking about Codable synthesis, or
encoding in general?

Yeah, I meant specifically in the case where things are synthesized
automatically. As you point out below, if someone implements a custom
Codeable instance, all bets are off.

On 21 Mar 2017, at 8:44, Colin Barrett wrote:

Hi Itai,

Glad to see these proposal! I'm curious, have you or the other Swift folks
thought about how *users* of these new Codable protocols will interact with
resilience domains?

What I mean is that what appear to be private or internal identifiers, and
thus changeable at will, may actually be fragile in that changing them will
break the ability to decode archives encoded by previous versions.

Making this safer could mean:
- Encoding only public properties

Unfortunately, property accessibility in code does not always map 1-to-1
with accessibility for archival (nor do I think they should be tied to one
another).
There are certainly cases where you’d want to include private information
in an archive, but that is not useful to expose to external clients, e.g.,
a struct/class version:

public struct MyFoo {
// Should be encoded.
public var title: String
public var identifier: Int

// This should be encoded too — in case the struct changes in the
// future, want to be able to refer to the payload version.
private let version = 1.0
}

Of course, there can also be public properties that you don’t find useful
to encode. At the moment, I’m not sure there’s a much better answer than
"the author of the code will have to think about the representation of
their data"; even if there were an easier way to annotate "I definitely
want this to be archived"/"I definitely don’t want this to be archived",
the annotation would still need to be manual.

(The above applies primarily in the case of Codable synthesis; when
implementing Codable manually I don’t think the compiler should ever
prevent you from doing what you need.)

- Adding some form of indirection (a la ObjC non-fragile ivars?)

What do you mean by this?

I'm not sure exactly how or if it would work in-detail, unfortunately, but
I know that the ObjC runtime emits symbols which are used to lookup the
offset in the object struct for non-fragile ivars. Maybe some similar form
of indirection would be useful for encoding non-public ivars. Like I said,
don't know exactly how/if that would work, just sharing :)


- Compiler warning (or disallowing) changes to properties in certain
situations.

We’ve thought about this with regards to identifying classes uniquely
across renaming, moving modules, etc.; this is a resilience problem in
general.
In order for the compiler to know about changes to your code it’d need to
keep state across compilations. While possible, this feels pretty fragile
(and potentially not very portable).

   - Compiler warns about changing a property? Blow away the cache
   directory!
   - Cloning the code to a new machine for the first time? Hmm, all the
   warnings went away…

This would be nice to have, but yes:

I imagine the specifics would need to follow the rest of the plans for
resilience.

specifics on this would likely be in line with the rest of resilience plans
for Swift in general.


Right. Thus my concern about allowing non-public fields to be automatically
serialized. The most conservative option would be to only automatically
synthesize a Codeable instance for the public members of public types.
Seems overly restrictive, so maybe anything goes for internal types, or
there's some sort of warning (overridable via an attribute?)

I want to emphasize btw that I'm enthusiastic about this proposal in
general. The support for integer keys is welcome and, as it's one of my pet
projects, eases support for a Cap'n Proto-style serialization format.[1]

-Colin

[1]: https://capnproto.org

It's likely that this could be addressed by a future proposal, as for the
time being developers can simply "not hold it wrong" ;)

Thanks,
-Colin

On Wed, Mar 15, 2017 at 6:52 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

Hi everyone,

The following introduces a new Swift-focused archival and serialization
API as part of the Foundation framework. We’re interested in improving the
experience and safety of performing archival and serialization, and are
happy to receive community feedback on this work.

Because of the length of this proposal, the *Appendix* and *Alternatives
Considered* sections have been omitted here, but are available in the full
proposal  on the
swift-evolution repo. The full proposal also includes an *Unabridged API*
for


further consideration.

Without further ado, inlined below.

— Itai

Swift Archival & Serialization

- Proposal: SE- 
- Author(s): Itai Ferber 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  > wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>>> > that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access users).  
>> To do that, we need a clear idea of the composition of both groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
>> not good enough when we introduced the feature, that required argument and 
>> clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in this 
> thread.
> 
>>> > By default, I did not mean the syntactic default of the language but the 
>>> > access modifier users will use “by default” when trying to restrict 
>>> > visibility. In most languages, that keyword is “private” so its valid to 
>>> > say that newcomers to the language will “default” to using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed restricted 
>> the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is file-visible?  
>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>> and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does things 
> differently for a good reason. I can't stop from quoting Xiaodi from a month 
> back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 
>> A user who wants a middle-ground visibility would “default” to “protected”, 
>> “friend”, “partial”, or similar.  After that does not compile, they will use 
>> google to find a middle-road visibility keyword, for which the only 
>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>> not a reasonable expectation of what the keyword means to a new Swift 
>> developer.
>> 
>> The popularity of private “as a default” is simply because many users prefer 
>> to hide their implementation details as a matter of routine code hygiene.  
>> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use private as 
> often as possible and relegate to fileprivate when the design leaves no other 
> choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate all 
> the time and the language feels like it has an unnecessary access modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is very 
> rare. As a consequence, we should try to only keep one. Removing fileprivate 
> is a no-go with extensions so that leaves us with removing private.

Removing scoped access is a no-go if we consider tightly encapsulating 
invariant-preserving state to be an important feature.  The fact is that both 
features can be used meaningfully.  The fact that some people choose not to do 
this is not an argument against the features being available.  It is an 
opportunity to encourage people to thing more carefully about why they are 
encapsulating something.  

A programmer has to make a conscious decision to give a declaration visibility 
other than internal.  If they have trouble identifying whether file or scoped 
access is appropriate this indicates they don’t really understand their intent 
in encapsulating the declaration very clearly.  I don’t think it’s a bad thing 
to ask people to think about this a little bit more.  A simple guideline is to 
use file-level access unless you have a specific reason for preferring the 
tight encapsulation scoped access provides.  Both Drew and I have offered some 
examples of specific reasons for using scoped access that IMO are important 
enough that they deserve to be supported by the language.

> 
>> I agree with several here (as I did in SE-0025) that our access modifiers 
>> are not well-named.  However, that’s not the proposal in front of us.
>> 
>>> > My own statistics in my 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charlie Monroe via swift-evolution]

> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 8:26 AM, Slava Pestov >> > wrote:
>>> 
 
 On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
 > wrote:
 
 -1 on this as well for similar reasons. Places where I use fileprivate 
 (aside from what was automatically migrated by Xcode) can be counted on 
 fingers of one or two hands. 
 
 I feel that this proposal is reverting something without offering an 
 alternative solution.
>>> 
>>> In what situations do you use Swift 3 private where fileprivate is not an 
>>> acceptable replacement?
>> 
>> In my usage, I very rarely use fileprivate. To back this with numbers, a 
>> recent project I developed (i.e. without Xcode's automatic migration of 
>> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 
>> uses of "private”.
> 
> Do you have a way to tell how much of the private is effectible fileprivate? 
> (top level private usage)

Yes, 19 cases (out of those 160). Mostly for private classes or 
identifiers/constants.

In another project (a framework I use in all my projects):

private (total): 335
top-level private: 65 (out of those 335)
fileprivate: 41

And I know about a place or two that's not properly written and if I refactored 
it properly, I'd get rid of another 20 fileprivates.

In my experience (for me - please don't take it as if I am judging anyone - not 
at all), the use of fileprivate indicates either improper public API (and by 
public I mean even internal - exposed out of the file); or that there could be 
other mechanisms for handling this (protected scope for subclasses/enclosing 
types).

> 
> 
> 
>> 
>> This is definitely a personal opinion, but I tend to limit access to members 
>> as much as possible to discourage/prevent their usage out of the scope they 
>> are intended for and to better design API that should be used out of the 
>> scope (public/internal). I feel this is a good thing for newcomers to a 
>> codebase (and myself coming back to a codebase after a year or two) as 
>> Xcode's autocompletion won't offer members that are not supposed to be 
>> called out of the scope (scope-private). 
>> 
>> As I've mentioned this during the discussion, I feel that current state of 
>> things encourages huge files (1000+ lines of code) as you can't define 
>> "protected" level access and migrate some of the code that implements e.g. 
>> accessibility to a different file without potentially exposing internal 
>> details to the rest of the module (if the extension in the other file needs 
>> access to private details, which is often the case).
>> 
>> I feel that if there should be a change to the access levels, it should 
>> address this as well. The current solution based on reverting the original 
>> proposal only unnecessarily exposes implementational details to the rest of 
>> the file - at least in my codebase.
>> 
>>> 
>>> Slava
>>> 
 
> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
> > wrote:
> 
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>  
>> 
> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
> explained my concerns.
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
"A lot of talk" is not the evidence supporting the proposal: it's just a 
warning that something may be very controversial among the community. The 
arguments for the revert are in the proposal and in the discussions in this 
thread.

>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.

It has pointed quite a few times by core team members that comparison to 
languages is not a very strong arguments, especially when Swift does things 
differently for a good reason. I can't stop from quoting Xiaodi from a month 
back:

«The beauty of Swift 2's access modifiers was that they were based around files 
and modules, explicitly rejecting types and scopes as units for determining 
visibility.» -- Xiaodi

> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.

The point is that keeping both private and fileprivate feels like an 
un-necessary complication:

• either a programmer falls on your side of the fence and will use private as 
often as possible and relegate to fileprivate when the design leaves no other 
choice. At that point it feels like a language wart.
• or a programmer will fall on my side of the fence and use fileprivate all the 
time and the language feels like it has an unnecessary access modifier.

I'd argue that the cases when a programmer will use both meaningfully is very 
rare. As a consequence, we should try to only keep one. Removing fileprivate is 
a no-go with extensions so that leaves us with removing private.

> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
I can generate statistics from my projects if you want. But it's unnecessary: I 
haven't used private once since it's introduction in Swift 3. I don't see the 
advantages it brings worth the trouble.
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
The migrator migrated to fileprivate everywhere, not private, disagreeing with 
your use of fileprivate.

>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
Some people used the for(;;) loop, the ++ operator, var parameters. Many other 
features were removed from Swift to simplify he language, make it more 
consistent. Those are 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 8:26 AM, Slava Pestov > > wrote:
>> 
>>> 
>>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
>>> -1 on this as well for similar reasons. Places where I use fileprivate 
>>> (aside from what was automatically migrated by Xcode) can be counted on 
>>> fingers of one or two hands. 
>>> 
>>> I feel that this proposal is reverting something without offering an 
>>> alternative solution.
>> 
>> In what situations do you use Swift 3 private where fileprivate is not an 
>> acceptable replacement?
> 
> In my usage, I very rarely use fileprivate. To back this with numbers, a 
> recent project I developed (i.e. without Xcode's automatic migration of 
> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses 
> of "private”.

Do you have a way to tell how much of the private is effectible fileprivate? 
(top level private usage)



> 
> This is definitely a personal opinion, but I tend to limit access to members 
> as much as possible to discourage/prevent their usage out of the scope they 
> are intended for and to better design API that should be used out of the 
> scope (public/internal). I feel this is a good thing for newcomers to a 
> codebase (and myself coming back to a codebase after a year or two) as 
> Xcode's autocompletion won't offer members that are not supposed to be called 
> out of the scope (scope-private). 
> 
> As I've mentioned this during the discussion, I feel that current state of 
> things encourages huge files (1000+ lines of code) as you can't define 
> "protected" level access and migrate some of the code that implements e.g. 
> accessibility to a different file without potentially exposing internal 
> details to the rest of the module (if the extension in the other file needs 
> access to private details, which is often the case).
> 
> I feel that if there should be a change to the access levels, it should 
> address this as well. The current solution based on reverting the original 
> proposal only unnecessarily exposes implementational details to the rest of 
> the file - at least in my codebase.
> 
>> 
>> Slava
>> 
>>> 
 On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
 > wrote:
 
 
> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  > wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
> through March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
 -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
 explained my concerns.
 
 
 -- 
 Greg Parker gpar...@apple.com  Runtime 
 Wrangler
 
 
 ___
 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] [Proposal] Factory Initializers

[Charlie Monroe via swift-evolution]

This was kind of my point - all current class initializers are allocating. 
Allowing non-allocating initializers would solve most cases, including factory 
methods.

The last else statement in your example (for a regular case) can definitely 
return a value from another initializer - e.g. init(reservingCapacity:).

I wouldn't go for the return statement, but rather assignment to self - this is 
more in line with to how the convenience initializers work - you can branch 
based on the input and call designated initializers accordingly.

The same way, you could assign to self and then access instance variables 
within self.

Taking your example, all returns would be assignment to self and the last 
branch of the if-else statement would read as follows:

self = self.init(reservingCapacity: cnt)
for idx in 0.. On Mar 21, 2017, at 6:04 PM, Philippe Hausler  wrote:
> 
> One concept to consider here is that the initializers that are factories may 
> or may not replace self;
> 
> Take for example NSArray (inspired from the objective-c implementation but 
> written in swift, but note this is not the only use case)
> 
> public init(objects: UnsafePointer!, count cnt: Int) {
> if count == 0 && type(of: self) == NSArray.self {
> // specialized NSArray that does not contain any objects; it is a 
> singleton so we dont need to allocate at all
> return __NSArray0.zeroElementSingleton
> } else if count == 1 type(of: self) == NSArray.self {
> // The single object version is more effecient since it does not need 
> to indirect to a buffer
> return __NSArray1(objects.pointee)
> } else if type(of: self) == NSArray.self {
> return CFArrayCreate(kCFAllocatorSystemDefault, 
> UnsafeMutablePointer(objects), cnt, )
> } else {
> _storage.reserveCapacity(cnt)
> for idx in 0.. _storage.append(objects[idx])
> }
> }
> }
> 
> This would mean that in the cases of 0 elements when NSArray itself is 
> created we can avoid allocating, when the count is 1 and it is an NSArray 
> itself we can emit a more effecient storage, then when the type is immuatable 
> we can fall to CF, and finally in the abstract case we can store elements in 
> a buffer directly.
> 
>> On Mar 21, 2017, at 4:28 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> I believe that this proposal is trying to solve something that can be solved 
>> by allowing assignment to self within convenience initializers. 
>> 
>> Unfortunately, even convenience initializers are allocating which makes it 
>> harder to achieve with backward compatibility - though I'm not entirely sure 
>> what would be the consequences of turning them into non-allocating.
>> 
>> If it's not possible due to implementational details, I'd suggest to rather 
>> introduce a @nonallocating (or similar) annotation (keyword?) that can be 
>> placed on init methods and it would then require for self to be assigned 
>> during the initialization as long as the assigned value is subtype of the 
>> receiver:
>> 
>> @nonallocating init(x: Int) {
>>  if x < 0 {
>>  self = NegativeMe(x: x)
>>  } else {
>>  self = PositiveMe(x: x)
>>  }
>> }
>> 
>> Which is pretty much what the proposal is suggesting, but removes the 
>> "factory" keyword which may be a bit misleading or narrowly named.
>> 
>> 
>>> On Mar 21, 2017, at 4:49 PM, David Rönnqvist via swift-evolution 
>>> > wrote:
>>> 
>>> Forgive me if that has already been discussed in the email threads prior to 
>>> the proposal, but what I’m missing from this proposal is a discussion of 
>>> the problems factory initializers solve (other than the examples at the 
>>> end) and an explanation of why factory initializers are the right solution 
>>> to that/those problems in Swift.
>>> 
>>> I acknowledge that it’s a common pattern in many languages, but don’t find 
>>> it a very strong argument as to why it should be built into the language. 
>>>  
>>> Regards,
>>> David
>>> 
>>> 
 On 17 Mar 2017, at 17:26, Riley Testut via swift-evolution 
 > wrote:
 
 Hi again everyone!
 
 Now that Swift 4 Stage 2 proposals are being considered, I thought it 
 might be time to revisit this proposal and see if it might align with the 
 goals set forth for Swift 4.
 
 As a quick tl;dr, this proposal describes a new "factory initializer" that 
 would allow you to return a value from an initializer. This would have 
 several benefits, as mentioned in the proposal itself as well as 
 throughout this mailing list. For convenience, here's a link to the 
 proposal on GitHub: 
 https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
  
 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

True indeed… but can we agree that this is just an hypothetic example, and no 
issue that is likely to happen in productive code?
Or is this actually taken from one of the projects you measured?
Here is the expanded edition which is productive.

/**A dummy return value to indicate a method isn't threadsafe.
 Because unused return values produce warnings in Swift, a caller who uses the 
method absentmindedly will have a warning in their code.  This can be 
suppressed with `let _: NotThreadSafe` from the caller. */
struct NotThreadSafe { }

///There are many cache implementations with different performance 
characteristics.
///we model them with a protocol.
protocol CacheImplementation {
    func prune() -> NotThreadSafe
}

///Many components share a single cache, so we expose it as a reference type
class Cache {
    
    init() { preconditionFailure("Provide a constructor to satisfy the 
compiler") }
    private var v: CacheImplementation
    private let lock = DispatchQueue(label: "lock")
    
    
    private func prune() -> NotThreadSafe {
        v.prune()
        return NotThreadSafe()
    }
    ///expose a threadsafe API to callers
    internal func prune() {
        lock.sync {
            //supress the warning, since we have a lock.
            let _: NotThreadSafe = self.prune()
        }
    }
}

extension Cache {
    func pruneAgressively() {
        for _ in 0..<5 {
            self.prune()
        }
    }
}

Note that, in this example, the scoped access keyword actually makes extensions 
*easier*, not harder, to write, because the extension does not need to choose 
between a safe and unsafe version of the method.

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Itai Ferber via swift-evolution]

Hi Colin,

Thanks for your comments! Are you talking about `Codable` synthesis, or 
encoding in general?


On 21 Mar 2017, at 8:44, Colin Barrett wrote:


Hi Itai,

Glad to see these proposal! I'm curious, have you or the other Swift 
folks
thought about how *users* of these new Codable protocols will interact 
with

resilience domains?

What I mean is that what appear to be private or internal identifiers, 
and
thus changeable at will, may actually be fragile in that changing them 
will

break the ability to decode archives encoded by previous versions.

Making this safer could mean:
- Encoding only public properties
Unfortunately, property accessibility in code does not always map 1-to-1 
with accessibility for archival (nor do I think they should be tied to 
one another).
There are certainly cases where you’d want to include private 
information in an archive, but that is not useful to expose to external 
clients, e.g., a struct/class version:


```swift
public struct MyFoo {
// Should be encoded.
public var title: String
public var identifier: Int

// This should be encoded too — in case the struct changes in the
// future, want to be able to refer to the payload version.
private let version = 1.0
}
```

Of course, there can also be public properties that you don’t find 
useful to encode. At the moment, I’m not sure there’s a much better 
answer than "the author of the code will have to think about the 
representation of their data"; even if there were an easier way to 
annotate "I definitely want this to be archived"/"I definitely don’t 
want this to be archived", the annotation would still need to be manual.


(The above applies primarily in the case of `Codable` synthesis; when 
implementing `Codable` manually I don’t think the compiler should ever 
prevent you from doing what you need.)



- Adding some form of indirection (a la ObjC non-fragile ivars?)

What do you mean by this?


- Compiler warning (or disallowing) changes to properties in certain
situations.
We’ve thought about this with regards to identifying classes uniquely 
across renaming, moving modules, etc.; this is a resilience problem in 
general.
In order for the compiler to know about changes to your code it’d need 
to keep state across compilations. While possible, this feels pretty 
fragile (and potentially not very portable).


* Compiler warns about changing a property? Blow away the cache 
directory!
* Cloning the code to a new machine for the first time? Hmm, all the 
warnings went away…


This would be nice to have, but yes:


I imagine the specifics would need to follow the rest of the plans for
resilience.
specifics on this would likely be in line with the rest of resilience 
plans for Swift in general.


It's likely that this could be addressed by a future proposal, as for 
the

time being developers can simply "not hold it wrong" ;)

Thanks,
-Colin

On Wed, Mar 15, 2017 at 6:52 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:


Hi everyone,

The following introduces a new Swift-focused archival and 
serialization
API as part of the Foundation framework. We’re interested in 
improving the
experience and safety of performing archival and serialization, and 
are

happy to receive community feedback on this work.
Because of the length of this proposal, the *Appendix* and 
*Alternatives
Considered* sections have been omitted here, but are available in the 
full

proposal  on the
swift-evolution repo. The full proposal also includes an *Unabridged 
API* for

further consideration.

Without further ado, inlined below.

— Itai

Swift Archival & Serialization

   - Proposal: SE- 

   - Author(s): Itai Ferber , Michael 
LeHew
   , Tony Parker 


   - Review Manager: TBD
   - Status: *Awaiting review*
   - Associated PRs:
  - #8124 
  - #8125 

Introduction

Foundation's current archival and serialization APIs (NSCoding,
NSJSONSerialization, NSPropertyListSerialization, etc.), while 
fitting
for the dynamism of Objective-C, do not always map optimally into 
Swift.

This document lays out the design of an updated API that improves the
developer experience of performing archival and serialization in 
Swift.


Specifically:

   - It aims to provide a solution for the archival of Swift struct 
and

   enum types
   - It aims to provide a more type-safe solution for serializing to
   external formats, such as JSON and plist

Motivation

The primary motivation for this proposal is the inclusion of native 
Swift

enum and struct types in archival and serialization. Currently,
developers targeting Swift cannot participate in NSCoding without 
being
willing to abandon enum and structtypes — NSCoding is an @objc 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Shawn Erickson via swift-evolution]

I have a few cases like that in production code with an unthread safe
private function shadows a more public function that applies thread safety
for external callers, etc.

-Shawn

On Tue, Mar 21, 2017 at 9:37 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Fact is, you can replace every occurrence of "private" with
> "fileprivate", and your source would compile as before, whereas fileprivate
> saves us from a "friend"-keyword.
>
> This is certainly a source-breaking change.  Consider:
>
> struct Foo {
>
> fileprivate func foo()->String {return "foo" }
>
> private func foo()->Int {return 2}
>
> }
>
> print("\(Foo().foo())")
>
> Replacing “private” with “fileprivate” here will introduce a compile error.
>
> True indeed… but can we agree that this is just an hypothetic example, and
> no issue that is likely to happen in productive code?
> Or is this actually taken from one of the projects you measured?
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[James Berry via swift-evolution]

-1.

While I agree generally that access control in swift is not yet perfect, I feel 
strongly that any further reshaping of access control primitives should wait 
until a submodule design is in place. To do another zag on this issue at this 
point seems preliminary, tweaky, and almost capricious towards our users. The 
access primitives established by SE-0025 added further control. Some may not 
like the naming. But it seems to me that as we contemplate potential further 
shifts down the line with submodules, we’re better off starting from where we 
are today, at a higher level of specificity.


> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 

> What is your evaluation of the proposal?
The proposal doesn’t to me meet the high hurdles for change in the swift 4 
timeframe. The current situation isn’t broken or horrible. I believe the 
SE-0025 semantics better position us for any access level changes that may be 
required if submodules are adopted.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
No

> Does this proposal fit well with the feel and direction of Swift?
No

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I feel this proposal goes in the wrong direction vis-a-vis expectations for 
access control.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve closely followed SE-0025 and SE-0159 discussions across the immense 
breadth of space and time they have consumed.

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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 11:24 AM, Colin Barrett  
> wrote:
> 
> I'm not sure I follow. What do you mean "which strategy to use for a given 
> encoding"? IMO there should be at most one implementation of Coding / 
> Decoding for a particular type. So the way you'd say "I want to decode a JSON 
> response that implements my blog model" would be, reusing the definition from 
> above
> 
> let wblog = try JSONDecoder().decode(WebBlogModel.self, from: payload)
> let blog = wblog.wrapped
> 
> What am I missing?

When I have encountered a need for things like this I usually don’t need to 
encode a whole tree differently based on context.  I only need to encode one or 
two types differently based on context.  IMO it would be insane to require 
wrapper types all the way down the tree that’s getting encoded just so that one 
or two types can encode themselves using a format specified by a server.  I 
suppose you could make it work but it’s crazy and unnecessary complexity if you 
ask me.

Brent’s example was using different formats for local archiving and for cloud 
persistence.  This also seems reasonable.  Again wrappers would work but would 
also be a lot of boilerplate for no obvious win.

Encoder and Decoder as proposed already include a `codingKeyContext`.  We’re 
just asking for an additional user-defined context which gives information 
about the purpose of the encoding.

> 
> -Colin
> 
> 
> On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson  > wrote:
>> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution 
>> > wrote:
>> 
>> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch 
>> and post BlogPosts to a cross-platform web service, and store them locally. 
>> But when I fetch and post remotely, I ned to conform to the web service's 
>> formats; when I store an instance locally, I have a freer hand in designing 
>> my storage, and perhaps need to store some extra metadata. How do you 
>> imagine handling that sort of situation? Is the answer simply that I should 
>> use two different types?
>> 
>> This is a valid concern, and one that should likely be addressed.
>> 
>> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] 
>> (UserInfoKey being a String-RawRepresentable struct or similar) on Encoder 
>> and Decoder set at the top-level to allow passing this type of contextual 
>> information from the top level down.
>> 
>>  
>> I assumed that in those situations, one would create a wrapper struct,
>> 
>> struct WebBlogModel {
>> let wrapped: BlogModel
>> }
>> 
>> probably for the encoding impl that requires more custom work. The 
>> implementation of Codable for this struct would then serialize (deserialize) 
>> from (to) its wrapped value's properties directly.
>> 
>> Types already provide a means for performing context sensitive 
>> implementation selection, I don't think it's necessary to provide another 
>> way to do that in Swift. Of course I could very well be wrong :)
> 
> Wrappers like this give you a way to implement different encoding strategies 
> but they don’t help you identify which strategy to use for a given encoding.  
> You need a user-defined context to do that.  Brent has proposed a couple of 
> different designs to facilitate this which are nicer than a user info 
> dictionary.
> 
>> 
>> -Colin
> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Ross O'Brien via swift-evolution]

   - What is your evaluation of the proposal?

In general: against.
Scope-based access is useful and should not be removed.
The fileprivate keyword is long and awkward to say, but unambiguous in
purpose. 'Private' is ambiguous, referring to scope-based access inside a
scope but file-based access outside a scope; this is the more complex term.

I would be in favour of a modified Alternative #3: assigning one keyword to
file-based access and one keyword to scope-based access. However, as
discussed at length during SE-0025, neither level is intuitively the
correct choice to be 'private'.

I would also be in favour of Matthew Johnson's proposal for un-complecting
access from capability - the proposed syntax would address this problem,
though the proposed access-alias feature intended to ensure code is not
broken by its change would not address this problem.


   - Is the problem being addressed significant enough to warrant a change
   to Swift?

A change is required, but not significantly enough to apply the 'solution'
proposed.


   - Does this proposal fit well with the feel and direction of Swift?

No.


   - If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?

This proposal removes a useful feature.


   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

Quick reading.

On Tue, Mar 21, 2017 at 4:12 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> > I’m not arguing that it is less or more than a majority. I’m just saying
> that we’ve seen a lot of talk against the original change.
>
> This proposal asks us to balance the convenience of one group
> (extension-writers) against the existence of another (scoped-access
> users).  To do that, we need a clear idea of the composition of both groups.
>
> “A lot of talk” is not the evidentiary standard to remove a feature.  It
> was not good enough when we introduced the feature, that required argument
> and clear use-cases.
>
> > By default, I did not mean the syntactic default of the language but the
> access modifier users will use “by default” when trying to restrict
> visibility. In most languages, that keyword is “private” so its valid to
> say that newcomers to the language will “default” to using that one.
>
> Apologies, but I do not understand the argument:
>
>1. A user wants to restrict visibility (e.g. they are dissatisfied
>with “internal”)
>2. The user *chooses* private because of familiarity from another
>language
>3. The user is then surprised that their choice of private indeed
>restricted the visibility, thus achieving their goal?
>
> What language does the user come from in which “private” is file-visible?
> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of,
> and it isn’t at all close.
>
> A user who wants a middle-ground visibility would “default” to
> “protected”, “friend”, “partial”, or similar.  After that does not compile,
> they will use google to find a middle-road visibility keyword, for which
> the only candidate is “fileprivate”.  But they will not choose “private”,
> it’s just not a reasonable expectation of what the keyword means to a new
> Swift developer.
>
> The popularity of private “as a default” is simply because many users
> prefer to hide their implementation details as a matter of routine code
> hygiene.  Redefining private in order to thwart their code hygiene goal
> seems extreme.
>
> I agree with several here (as I did in SE-0025) that our access modifiers
> are not well-named.  However, that’s not the proposal in front of us.
>
> > My own statistics in my projects show the contrary. At best, this shows
> how divisive this feature is.
>
> This *may* show that, if contrary statistics were presented, but that
> hasn’t occurred.
>
>
>- In old code, statistics could be biased by the migrator having
>replaced all previous instances of private by fileprivate.
>
> If the migrator migrated code to private, and it *worked* (e.g. did not
> introduce visibility errors) this is not bias, this is a correct use of the
> feature.
>
> > I'm just arguing that the additional scope-based access modifier does
> not provide enough differentiation to be worth that complexity.
>
> The only argument I have seen so far around “complexity” boils down to:
> “some people do not use it”.  But some people *do* use it, and anyway if we
> are going to remove all the features “not enough people” use then we are in
> for a ride.
>
> Swift 3 shipped, so what we are discussing now is yanking a keyword
> without replacement.  There is code written that uses private to enforce
> its threading or security invariants.  There is code written that uses
> private in order to shadow another declaration.   There is code that will
> not compile after 

Re: [swift-evolution] [Proposal] Factory Initializers

[Charlie Monroe via swift-evolution]

I believe that this proposal is trying to solve something that can be solved by 
allowing assignment to self within convenience initializers. 

Unfortunately, even convenience initializers are allocating which makes it 
harder to achieve with backward compatibility - though I'm not entirely sure 
what would be the consequences of turning them into non-allocating.

If it's not possible due to implementational details, I'd suggest to rather 
introduce a @nonallocating (or similar) annotation (keyword?) that can be 
placed on init methods and it would then require for self to be assigned during 
the initialization as long as the assigned value is subtype of the receiver:

@nonallocating init(x: Int) {
if x < 0 {
self = NegativeMe(x: x)
} else {
self = PositiveMe(x: x)
}
}

Which is pretty much what the proposal is suggesting, but removes the "factory" 
keyword which may be a bit misleading or narrowly named.


> On Mar 21, 2017, at 4:49 PM, David Rönnqvist via swift-evolution 
>  wrote:
> 
> Forgive me if that has already been discussed in the email threads prior to 
> the proposal, but what I’m missing from this proposal is a discussion of the 
> problems factory initializers solve (other than the examples at the end) and 
> an explanation of why factory initializers are the right solution to 
> that/those problems in Swift.
> 
> I acknowledge that it’s a common pattern in many languages, but don’t find it 
> a very strong argument as to why it should be built into the language. 
>  
> Regards,
> David
> 
> 
>> On 17 Mar 2017, at 17:26, Riley Testut via swift-evolution 
>> > wrote:
>> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>>  
>> 
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian > > wrote:
>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
 > wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
> > wrote:
> 
> Recently, I proposed the idea of adding the ability to implement the 
> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
> discussed it and came up with different approaches, it evolved into a 
> functionality that I believe is far more beneficial to Swift, and 
> subsequently should be the focus of its own proposal. So here is the 
> improved (pre-)proposal:
> 
> # Factory Initializers
> 
> The "factory" pattern is common in many languages, including Objective-C. 
> Essentially, instead of initializing a type directly, a method is called 
> that returns an instance of the appropriate type determined by the input 
> parameters. Functionally this works well, but ultimately it forces the 
> client of the API to remember to call the factory method instead, rather 
> than the type's initializer. This might seem like a minor gripe, but 
> given that we want Swift to be as approachable as possible to new 
> developers, I think we can do better in this regard.
> 
> Rather than have a separate factory method, I propose we build the 
> factory pattern right into Swift, by way of 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Colin Barrett via swift-evolution]

I'm not sure I follow. What do you mean "which strategy to use for a given
encoding"? IMO there should be at most one implementation of Coding /
Decoding for a particular type. So the way you'd say "I want to decode a
JSON response that implements my blog model" would be, reusing the
definition from above

let wblog = try JSONDecoder().decode(WebBlogModel.self, from: payload)
let blog = wblog.wrapped

What am I missing?

-Colin


On Tue, Mar 21, 2017 at 12:16 PM Matthew Johnson 
wrote:

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch
> and post BlogPosts to a cross-platform web service, and store them locally.
> But when I fetch and post remotely, I ned to conform to the web service's
> formats; when I store an instance locally, I have a freer hand in designing
> my storage, and perhaps need to store some extra metadata. How do you
> imagine handling that sort of situation? Is the answer simply that I should
> use two different types?
>
> This is a valid concern, and one that should likely be addressed.
>
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] (
> UserInfoKey being a String-RawRepresentable struct or similar) on Encoder
> and Decoder set at the top-level to allow passing this type of contextual
> information from the top level down.
>
>
> I assumed that in those situations, one would create a wrapper struct,
>
> struct WebBlogModel {
> let wrapped: BlogModel
> }
>
> probably for the encoding impl that requires more custom work. The
> implementation of Codable for this struct would then serialize
> (deserialize) from (to) its wrapped value's properties directly.
>
> Types already provide a means for performing context sensitive
> implementation selection, I don't think it's necessary to provide another
> way to do that in Swift. Of course I could very well be wrong :)
>
>
> Wrappers like this give you a way to *implement* different encoding
> strategies but they don’t help you identify which strategy to use for a
> given encoding.  You need a user-defined context to do that.  Brent has
> proposed a couple of different designs to facilitate this which are nicer
> than a user info dictionary.
>
>
> -Colin
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Davor Jankolija via swift-evolution]

> What is your evaluation of the proposal?

+ 1.

Don’t like to admit it but i favored the fileprivate modifier when it was 
introduced. Alas more experince with Swift has meant that I now very often 
catch myself changing private to fileprivate if for nothing else then to allow 
protocol conformance through extensions in the same file. Even though this may 
not be a good enough reason to make me go with supporting the proposal, the 
fact that access modifiers are fundamental to most modern PLs and fileprivate 
vs private as is is now adds too little while on the other hand adds another 
access modifier which IMHO should be simple and allow encapsluation (as some 
have said, internal and public are actually enough to achieve this) means for 
me this is something worth reverting.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.

> Does this proposal fit well with the feel and direction of Swift?

Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Most other languages encapsulate based on type and inheritance, so this strays 
a bit by making private extend beyond the class definition itself. However, no 
other language I’ve used make use of extensions the way Swift does so it makes 
sense in a Swift environment.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Followed both the original conversation added fileprivate as well as the other 
conversations which led to this proposal. 

- Davor

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Colin Barrett via swift-evolution]

On Mon, Mar 20, 2017 at 7:54 PM Douglas Gregor  wrote:

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
> through March 27, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>
> -1. The proposal does not make a convincing case for why this is a
problem.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Having to write "fileprivate" seems like a pretty minor annoyance.
Especially when compared to having to move any desired private data to a
new file. In my view, the primary purpose of access modifiers below
internal is to keep autocomplete from suggesting implementation details to
clients.
,

>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Given that in other places in Swift, scoping often corresponds with
lexical structure, making "private" an exception seems surprising.
"fileprivate" succinctly communicates this oddity.


>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> I've got a decent amount of experience with access control in Java,
Python, Haskell, and Standard ML.


>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>  I read the proposal once. (I didn't have time to read the follow-ups
on-list, apologies for any noise.)


> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[David Rönnqvist via swift-evolution]

> What is your evaluation of the proposal?
I’m positive towards this proposal in isolation. It’s a step in the right 
direction. But I also feel that it doesn’t fully address the larger issue 
around access control.  

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
The larger problem of access control definitely is. I can agree that the 
changes of SE-0025 were confusing and could be seen as harmful. If there’s a 
larger overhaul of access control coming in the future, then I’m not certain 
that the fileprivate/private problem is significant enough to warrant a change. 
But if there might be some time before there is a chance to revisit access 
control, then this might be significant enough to do now. 

> Does this proposal fit well with the feel and direction of Swift?
Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Objective-C effectively has a file based private access by not really having 
access control  and commonly putting “private” declarations in a category in 
the .m file.
Languages like Java has access control that is more targeted towards 
subclassing, where files doesn’t matter.
Languages like Haskell has access control based on files or modules, largely 
because of free functions. 

Swift isn’t exactly like either of these. It has proper enforceable access 
control, it has protocols and extensions, it prefers properties and member 
functions over free functions. 
I can’t think of any other language that has both a private and a file private 
scope. And if Swift were to have only one (again), then file private feels 
right for Swift, mainly for its use in same-file extensions.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read the proposal and participated in one of the the discussions leading up to 
it.


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

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution 
> > wrote:
> 
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch and 
> post BlogPosts to a cross-platform web service, and store them locally. But 
> when I fetch and post remotely, I ned to conform to the web service's 
> formats; when I store an instance locally, I have a freer hand in designing 
> my storage, and perhaps need to store some extra metadata. How do you imagine 
> handling that sort of situation? Is the answer simply that I should use two 
> different types?
> 
> This is a valid concern, and one that should likely be addressed.
> 
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] 
> (UserInfoKey being a String-RawRepresentable struct or similar) on Encoder 
> and Decoder set at the top-level to allow passing this type of contextual 
> information from the top level down.
> 
>  
> I assumed that in those situations, one would create a wrapper struct,
> 
> struct WebBlogModel {
> let wrapped: BlogModel
> }
> 
> probably for the encoding impl that requires more custom work. The 
> implementation of Codable for this struct would then serialize (deserialize) 
> from (to) its wrapped value's properties directly.
> 
> Types already provide a means for performing context sensitive implementation 
> selection, I don't think it's necessary to provide another way to do that in 
> Swift. Of course I could very well be wrong :)

Wrappers like this give you a way to implement different encoding strategies 
but they don’t help you identify which strategy to use for a given encoding.  
You need a user-defined context to do that.  Brent has proposed a couple of 
different designs to facilitate this which are nicer than a user info 
dictionary.

> 
> -Colin
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.
> 
> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
> Swift 3 shipped, so what we are discussing now is yanking a keyword without 
> replacement.  There is code written that uses private to enforce its 
> threading or security invariants.  There is code written that uses private in 
> order to shadow another declaration.   There is code that will not compile 
> after migration. We need more than a vague fear of complexity generally to 
> throw a brick through all those windows.  That brick will introduce quite a 
> bit of complexity itself.
> 
+1.  On one side we have a vague notion of “complexity” which doesn’t appear to 
amount to much more than a statement of opinion that the granularity isn’t 
useful.  On the other side we have people who find legitimate value in the 
feature for important and clearly articulated purposes.  This seems to me to be 
a solid demonstration that the feature is useful.  

Compiler verification of invariant-preserving encapsulation is important.  It 
is not trivial.  It is not something to be written off lightly because “you’re 
only protecting yourself from yourself”.  People make very similar arguments 
against static typing outside of the Swift community but most of us here see 
value in static types.  Frankly, I’m surprised that so many don’t see more 
value in compiler verified encapsulation.  Is it as important as a robust 
static type system?  No.  But that doesn’t make it unimportant.

>> Concerning the one-class-per-file argument, I would suggest this 
>> counter-argument: when working in large projects, I believe it's a good 
>> thing if the language encourages (forces is too strong a word for my taste) 
>> a one class per file structure, it's good practice.
> 
> The form of the argument is invalid.  Suppose I argued: "it’s a good thing 
> for the language to encourage one definition per 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Colin Barrett via swift-evolution]

On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Here's what I mean: Suppose I have a BlogPost model, and I can both fetch
> and post BlogPosts to a cross-platform web service, and store them locally.
> But when I fetch and post remotely, I ned to conform to the web service's
> formats; when I store an instance locally, I have a freer hand in designing
> my storage, and perhaps need to store some extra metadata. How do you
> imagine handling that sort of situation? Is the answer simply that I should
> use two different types?
>
> This is a valid concern, and one that should likely be addressed.
>
> Perhaps the solution is to offer a userInfo : [UserInfoKey : Any] (
> UserInfoKey being a String-RawRepresentable struct or similar) on Encoder
> and Decoder set at the top-level to allow passing this type of contextual
> information from the top level down.
>

I assumed that in those situations, one would create a wrapper struct,

struct WebBlogModel {
let wrapped: BlogModel
}

probably for the encoding impl that requires more custom work. The
implementation of Codable for this struct would then serialize
(deserialize) from (to) its wrapped value's properties directly.

Types already provide a means for performing context sensitive
implementation selection, I don't think it's necessary to provide another
way to do that in Swift. Of course I could very well be wrong :)

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Mark Sands via swift-evolution]

   - What is your evaluation of the proposal?

+0.5, with my preference being Alternative 2


   - Is the problem being addressed significant enough to warrant a change
   to Swift?

Yes. Others have pointed out that "the extension problem" could be
addressed by giving extensions access to private members within a module,
which would solve a lot of my grief but make fileprivate less applicable in
general.


   - Does this proposal fit well with the feel and direction of Swift?

Yes


   - If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?

No comment.


   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

A quick refresher of 25 and a quick reading of 159

On Mon, Mar 20, 2017 at 6:54 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
> through March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

> I’m not arguing that it is less or more than a majority. I’m just saying that 
> we’ve seen a lot of talk against the original change.
This proposal asks us to balance the convenience of one group 
(extension-writers) against the existence of another (scoped-access users).  To 
do that, we need a clear idea of the composition of both groups.

“A lot of talk” is not the evidentiary standard to remove a feature.  It was 
not good enough when we introduced the feature, that required argument and 
clear use-cases.

> By default, I did not mean the syntactic default of the language but the 
> access modifier users will use “by default” when trying to restrict 
> visibility. In most languages, that keyword is “private” so its valid to say 
> that newcomers to the language will “default” to using that one.
Apologies, but I do not understand the argument:

A user wants to restrict visibility (e.g. they are dissatisfied with “internal”)
The user *chooses* private because of familiarity from another language
The user is then surprised that their choice of private indeed restricted the 
visibility, thus achieving their goal?
What language does the user come from in which “private” is file-visible?  It 
isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and it 
isn’t at all close.

A user who wants a middle-ground visibility would “default” to “protected”, 
“friend”, “partial”, or similar.  After that does not compile, they will use 
google to find a middle-road visibility keyword, for which the only candidate 
is “fileprivate”.  But they will not choose “private”, it’s just not a 
reasonable expectation of what the keyword means to a new Swift developer.

The popularity of private “as a default” is simply because many users prefer to 
hide their implementation details as a matter of routine code hygiene.  
Redefining private in order to thwart their code hygiene goal seems extreme.

I agree with several here (as I did in SE-0025) that our access modifiers are 
not well-named.  However, that’s not the proposal in front of us.

> My own statistics in my projects show the contrary. At best, this shows how 
> divisive this feature is.
This *may* show that, if contrary statistics were presented, but that hasn’t 
occurred.

In old code, statistics could be biased by the migrator having replaced all 
previous instances of private by fileprivate.
If the migrator migrated code to private, and it *worked* (e.g. did not 
introduce visibility errors) this is not bias, this is a correct use of the 
feature.

> I'm just arguing that the additional scope-based access modifier does not 
> provide enough differentiation to be worth that complexity.
The only argument I have seen so far around “complexity” boils down to: “some 
people do not use it”.  But some people *do* use it, and anyway if we are going 
to remove all the features “not enough people” use then we are in for a ride.

Swift 3 shipped, so what we are discussing now is yanking a keyword without 
replacement.  There is code written that uses private to enforce its threading 
or security invariants.  There is code written that uses private in order to 
shadow another declaration.   There is code that will not compile after 
migration. We need more than a vague fear of complexity generally to throw a 
brick through all those windows.  That brick will introduce quite a bit of 
complexity itself.

Concerning the one-class-per-file argument, I would suggest this 
counter-argument: when working in large projects, I believe it's a good thing 
if the language encourages (forces is too strong a word for my taste) a one 
class per file structure, it's good practice.

The form of the argument is invalid.  Suppose I argued: "it’s a good thing for 
the language to encourage one definition per class (no extensions), it’s good 
practice.  So we do not need fileprivate.”  That would be very silly (although 
it has already been advanced as a straw-man position elsewhere in this thread). 
The argument that we do not need private because nobody should put multiple 
classes in a file is equally silly. There are reasons to do so, in fact one 
motivation was given in SE-0025:

> Putting related APIs and/or related implementations in the same file helps 
> ensure consistency and reduces the time to find a particular API or 
> implementation. 

These concerns are not resolved by arguments of the form “just don’t do that”.

I empathize with the Swift2 programmer who got through two releases without a 
scoped access modifier and is annoyed by change.  However, removing the feature 
now is more change, not less, so it makes their problem worse, not better.


On March 21, 2017 at 2:17:40 AM, David Hart (da...@hartbit.com) wrote:

Perhaps it was a mistake, but I purposefully did not go into too much detail in 
the proposal because I think this debate is purely a question of philosophy on 
Swift and its language features. I did not want to add un-necessary bloat that 
would 

Re: [swift-evolution] [Proposal] Factory Initializers

[David Rönnqvist via swift-evolution]

Forgive me if that has already been discussed in the email threads prior to the 
proposal, but what I’m missing from this proposal is a discussion of the 
problems factory initializers solve (other than the examples at the end) and an 
explanation of why factory initializers are the right solution to that/those 
problems in Swift.

I acknowledge that it’s a common pattern in many languages, but don’t find it a 
very strong argument as to why it should be built into the language. 
 
Regards,
David


> On 17 Mar 2017, at 17:26, Riley Testut via swift-evolution 
>  wrote:
> 
> Hi again everyone!
> 
> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
> be time to revisit this proposal and see if it might align with the goals set 
> forth for Swift 4.
> 
> As a quick tl;dr, this proposal describes a new "factory initializer" that 
> would allow you to return a value from an initializer. This would have 
> several benefits, as mentioned in the proposal itself as well as throughout 
> this mailing list. For convenience, here's a link to the proposal on GitHub: 
> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>  
> 
> 
> Would love to hear any more comments on this proposal, and if we feel this is 
> appropriate for considering for Swift 4 I'll happily re-open the pull request!
> 
> Riley Testut
> 
> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  > wrote:
> 
>> i would appreciate this feature.
>> 
>> For unexperienced developers, its often hard to recognize *when* factory is 
>> a good fit to do the job, and how exactly approach the implementation. I 
>> imagine having this feature built into the language may help to choose and 
>> implement factory when its the right thing to do.
>> 
>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>> > wrote:
>>> 
>>> Is there any chance of reviving this? It seems to me that since this would 
>>> require Swift initializers to be implemented internally in such a way that 
>>> they can return a value (as Objective-C init methods do), it may affect ABI 
>>> stability and thus may be germane to the current stage of Swift 4 
>>> development.
>>> 
>>> Charles
>>> 
 On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
 > wrote:
 
 Recently, I proposed the idea of adding the ability to implement the 
 "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
 discussed it and came up with different approaches, it evolved into a 
 functionality that I believe is far more beneficial to Swift, and 
 subsequently should be the focus of its own proposal. So here is the 
 improved (pre-)proposal:
 
 # Factory Initializers
 
 The "factory" pattern is common in many languages, including Objective-C. 
 Essentially, instead of initializing a type directly, a method is called 
 that returns an instance of the appropriate type determined by the input 
 parameters. Functionally this works well, but ultimately it forces the 
 client of the API to remember to call the factory method instead, rather 
 than the type's initializer. This might seem like a minor gripe, but given 
 that we want Swift to be as approachable as possible to new developers, I 
 think we can do better in this regard.
 
 Rather than have a separate factory method, I propose we build the factory 
 pattern right into Swift, by way of specialized “factory initializers”. 
 The exact syntax was proposed by Philippe Hausler from the previous 
 thread, and I think it is an excellent solution:
 
 class AbstractBase {
  public factory init(type: InformationToSwitchOn) {
  return ConcreteImplementation(type)
  }
 }
 
 class ConcreteImplementation : AbstractBase {
 
 }
 
 Why exactly would this be useful in practice? In my own development, I’ve 
 come across a few places where this would especially be relevant:
 
 ## Class Cluster/Abstract Classes
 This was the reasoning behind the original proposal, and I still think it 
 would be a very valid use case. The public superclass would declare all 
 the public methods, and could delegate off the specific implementations to 
 the private subclasses. Alternatively, this method could be used as an 
 easy way to handle backwards-compatibility: rather than litter the code 
 with branches depending on the OS version, simply return the 
 OS-appropriate subclass from the factory initializer. Very useful.
 
 ## Protocol Initializers
 Proposed by Brent Royal-Gordon, we could use factory 

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Colin Barrett via swift-evolution]

Hi Itai,

Glad to see these proposal! I'm curious, have you or the other Swift folks
thought about how *users* of these new Codable protocols will interact with
resilience domains?

What I mean is that what appear to be private or internal identifiers, and
thus changeable at will, may actually be fragile in that changing them will
break the ability to decode archives encoded by previous versions.

Making this safer could mean:
- Encoding only public properties
- Adding some form of indirection (a la ObjC non-fragile ivars?)
- Compiler warning (or disallowing) changes to properties in certain
situations.

I imagine the specifics would need to follow the rest of the plans for
resilience.

It's likely that this could be addressed by a future proposal, as for the
time being developers can simply "not hold it wrong" ;)

Thanks,
-Colin

On Wed, Mar 15, 2017 at 6:52 PM Itai Ferber via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everyone,
>
> The following introduces a new Swift-focused archival and serialization
> API as part of the Foundation framework. We’re interested in improving the
> experience and safety of performing archival and serialization, and are
> happy to receive community feedback on this work.
> Because of the length of this proposal, the *Appendix* and *Alternatives
> Considered* sections have been omitted here, but are available in the full
> proposal  on the
> swift-evolution repo. The full proposal also includes an *Unabridged API* for
> further consideration.
>
> Without further ado, inlined below.
>
> — Itai
>
> Swift Archival & Serialization
>
>- Proposal: SE- 
>- Author(s): Itai Ferber , Michael LeHew
>, Tony Parker 
>- Review Manager: TBD
>- Status: *Awaiting review*
>- Associated PRs:
>   - #8124 
>   - #8125 
>
> Introduction
>
> Foundation's current archival and serialization APIs (NSCoding,
> NSJSONSerialization, NSPropertyListSerialization, etc.), while fitting
> for the dynamism of Objective-C, do not always map optimally into Swift.
> This document lays out the design of an updated API that improves the
> developer experience of performing archival and serialization in Swift.
>
> Specifically:
>
>- It aims to provide a solution for the archival of Swift struct and
>enum types
>- It aims to provide a more type-safe solution for serializing to
>external formats, such as JSON and plist
>
> Motivation
>
> The primary motivation for this proposal is the inclusion of native Swift
> enum and struct types in archival and serialization. Currently,
> developers targeting Swift cannot participate in NSCoding without being
> willing to abandon enum and structtypes — NSCoding is an @objc protocol,
> conformance to which excludes non-class types. This is can be limiting in
> Swift because small enums and structs can be an idiomatic approach to
> model representation; developers who wish to perform archival have to
> either forgo the Swift niceties that constructs like enumsprovide, or
> provide an additional compatibility layer between their "real" types and
> their archivable types.
>
> Secondarily, we would like to refine Foundation's existing serialization
> APIs (NSJSONSerialization and NSPropertyListSerialization) to better
> match Swift's strong type safety. From experience, we find that the
> conversion from the unstructured, untyped data of these formats into
> strongly-typed data structures is a good fit for archival mechanisms,
> rather than taking the less safe approach that 3rd-party JSON conversion
> approaches have taken (described further in an appendix below).
>
> We would like to offer a solution to these problems without sacrificing
> ease of use or type safety.
> Agenda
>
> This proposal is the first stage of three that introduce different facets
> of a whole Swift archival and serialization API:
>
>1. This proposal describes the basis for this API, focusing on the
>protocols that users adopt and interface with
>2. The next stage will propose specific API for new encoders
>3. The final stage will discuss how this new API will interop with
>NSCoding as it is today
>
> SE- provides stages 2 and 3.
> Proposed solution
>
> We will be introducing the following new types:
>
>- protocol Codable: Adopted by types to opt into archival. Conformance
>may be automatically derived in cases where all properties are also
>Codable.
>- protocol CodingKey: Adopted by types used as keys for keyed
>containers, replacing String keys with semantic types. Conformance may
>be automatically derived in most cases.
>- protocol Encoder: Adopted by types which can take Codable values and
>encode them into a native 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 21, 2017 at 7:00:32 AM, Tino Heth (2...@gmx.de) wrote:

> If private is really more useful, should we remove fileprivate instead?
We don’t have to remove any access modifier.  They are all useful.

> Fact is, you can replace every occurrence of "private" with "fileprivate", 
> and your source would compile as before, whereas fileprivate saves us from a 
> "friend"-keyword.
This is certainly a source-breaking change.  Consider:

struct Foo {

    fileprivate func foo()->String {return "foo" }

    private func foo()->Int {return 2}   

}

print("\(Foo().foo())")

Replacing “private” with “fileprivate” here will introduce a compile error.





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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>  
>> 
> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
> explained my concerns.

I am also -1.  

I think there are two issues to be considered.  One is scoped access itself and 
the other is the names of the access levels.  

I think a reasonable case can be made that changing the meaning of private and 
introducing fileprivate was a mistake.  We probably should have left private 
alone and chosen a new name for scoped access.  There was abundant bikeshedding 
over this at the time, but now we have the benefit of experience.  I believe we 
should have simply called scoped access control `scoped`.  It’s clear that some 
people would still oppose scoped access but I also don’t think we’d be 
revisiting this topic if we hadn’t changed the meaning of `private`.  The 
passionate dislike of the feature seems to me mostly related to stealing the 
`private` keyword.  

I support correcting the naming mistake eventually.  I’m neutral as to whether 
Swift 4 is the right time to do that.  We just introduced a lot of churn in 
Swift 3.  There is still inconsistency in Swift’s access control system as well 
as unmet needs (especially around submodules).  It may be better to leave 
things alone for a release and make the change as part of a larger set of 
changes when access control and submodules are part of a release “theme”.

I am extremely unconvinced that having a scoped access level is actively 
harmful.  It introduces another choice in the language but no individual 
programmers or teams are forced to use the additional flexibility if they don’t 
want to.  It would be very easy for linters to prohibit scoped access if there 
are teams that don’t want to use it.  It is one extra degree of control for new 
programmers to learn but properly taught it helps programmers learn to think 
about encapsulation.  This is a good thing.

On the other hand, I believe removing scoped access is active harmful.  It 
reduces our ability to properly encapsulate mutable state.  For example, I like 
to use scoped access to create small state machine types which are used as part 
of the implementation of another type.  These are usually structs with a 
private enum.  The struct exposes methods which encapsulate state transitions.  
Without scoped access there is no way to encapsulate the state of the state 
machine and force all changes to go through one of the methods on the struct.  
This is just one example of how this feature can be very useful, there are many 
others.  Small helper types like this are very idiomatic in Swift.  It would be 
a big step backward to lose the ability to have proper encapsulation of small 
helper types.

One common argument agains scoped access is that “you’re only protecting 
yourself from yourself”.  I find this to be a bit of a straw man.  It isn’t 
about “protection”.  It is about compiler verified encapsulation.  This 
prevents inadvertent changes that violate the intent of the design.  For 
example, it is not out of the question that without scoped access a new member 
of a large team writes directly to the internal storage of the state machine in 
the above example.  It is also possible that they do so in a way that 
represents an invalid state transition.  The compiler would not catch this 
mistake.  Hopefully it would be caught in a code review but I can imagine it 
getting missed for many different reasons.  On the other hand, with scoped 
access the new team member would be unlikely to prefer changing access control 
to using the intended methods.  If they did change access control this would be 
very likely to be caught in code review.

Access control also provides compiler verified documentation of our code.  This 
facilitates reasoning about our code.  It also communicates design intent from 
the original author to future maintainers.  Removing a tool that many people 
find useful in facilitating reasoning about code is actively harmful.  Teams 
that don’t find this tool useful should use a linter and ban its use on their 
team.  This approach would let those of us who do find this tool useful 
continue to use it.

My observation thus far has been that people seem to be preferring private over 
fileprivate in many cases.  I don’t think this preference is solely about 
typing four less characters.  I think many people really do value the tighter 
encapsulation it provides.

I do think 

Re: [swift-evolution] Swift null safety questions

[Elijah Johnson via swift-evolution]

I still like the idea of shared memory, but since without additional
threading it can’t have write access inside the new process, I don’t think
that it is a solution for a webserver.

The main concern was just with developers using these universal exceptions
deliberately, along with “inconsistent states” and memory leaks.

So here’s a simple proposal:

func unsafeCatchFatalErrorWithMemoryLeak(_ block: ()->Void) -> FatalError?

What it does is execute the block, and when the fatalError function is
invoked (as is the case with logic errors), the fatalError checks some
thread local for the existence of this handler and performs a goto.
“unsafeCatchFatalErrorWithMemoryLeak” then returns a small object with the
error message. The can only be one per-call stack, and it leaks
deliberately leaks the entire stack from “fatalError” back down to
“unsafeCatchFatalErrorWithMemoryLeak”, and that is one reason why it is
labelled “unsafe” and “withMemoryLeak”.

The idea is that this is a function expressly for “high availability”
applications like web servers. The server will now have some leaked objects
posing no immediate danger, and some inconsistencies, primarily or entirely
inside the leaked objects (It is the developer’s responsibility how this is
used).

The “high availability sytem” is then expected to stop accepting incoming
socket connections, generate another instance of itself, handle any open
connections, and exit.

The interesting thing about this is that it is very easy to implement.
Being an unsafe function, it is not part of the language as a catch block
is, and doesn’t entirely preclude another solution in the future.


On March 14, 2017 at 8:22:11 PM, Elijah Johnson (ejrx7...@gmail.com) wrote:

But - that would require a dedicated thread or a thread pool to run
function calls on. Definitely it lacks many of the advantages of shared
objects directly in the process. I would definitely prefer a small memory
leak or inconsistent state. The server could handle existing requests and
restart itself if it were really an issue. A memory leak can be estimated
and the server restarted after every “x” times, while an inconsistent state
is something that happens in any shared server environment. The developers
just don’t modify the shared state until they have ready the final object,
and their array/dictionary put function call itself isn’t likely to be the
fail that happened.


On March 14, 2017 at 7:29:28 PM, Elijah Johnson (ejrx7...@gmail.com) wrote:

Also the proxies would need to implement some protocol so that they can be
de-proxied when sent back to a shared method, and the proxy object exposed
to the user with a new declaration that accepts only proxies. Like using
MyClass -> MyClassSharedProxy for the proxy class and

class MyClass {

func testReturnsObject() -> SomeClass
func call(a:MyClass) -> MyClass

}

would become

class MyClassSharedProxy : MyClass, SharedProxyProtocol {

func testReturnsObject() -> SomeClassSharedProxy
func call(a:MyClassSharedProxy) -> MyClassSharedProxy

}


for example.


On March 14, 2017 at 7:15:08 PM, Elijah Johnson (ejrx7...@gmail.com) wrote:

Sounds like a good idea. I assume that Swift would need to compile these
proxies in advance to be sub-classes ie. binary compatible objects that
will forward calls and return proxies. “Value” types can be copied as they
normally are, or wrapped by the user (along with “final” objects which
could be wrapped manually or made not-final). Then you’d just need a way to
get your first proxy object and a way to register the process’s object.
Something like

func openSharedObject(pid:String) throws -> Any? // cast to expected
value


func registerSharedProxyObject(object:Any) // for this process

I suppose the caller would have to be the one to compile these proxy
objects and locate them in its own module.

The advantage here is that it would be not too difficult for existing
servers to make use of this, as they are already written as a single
process in Swift and so they would just need to manage and pre-fork
processes instead of threads. Seems like it would also have numerous uses
in the systems programming domain.

Then one just needs, ideally, to get a stack trace and fatal error message
to the parent process if a child process crashes.




On March 14, 2017 at 12:18:37 AM, Brent Royal-Gordon (br...@architechies.com)
wrote:

> On Mar 13, 2017, at 5:54 PM, Matthew Johnson 
wrote:

>
> I suspect you're right about this for the most part but I think we will
want the ability for "failable processes" (or whatever they're called) to
have read-only access to shared state that outlives them. What I can't
imagine is allowing them write access to state that is shared.

The problem there is that shared data in Swift always has a retain count,
so we'd need some way to track when code in one of these "mini-processes"
retains an external object so we can release it if it crashes. Perhaps
you'd need to wrap 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Tino Heth via swift-evolution]

> Yes. To cite some evidence, here are codebases I actively maintain:
> 
> | codebase   | private # | 
> fileprivate # | ratio |
> 
> ||---|---|---|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x|
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x|
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH 
>  | 15| 1   
>   | 15x   |
> 
> | atbuild https://github.com/AnarchyTools/atbuild 
> | 54| 5 
> | 11x   |
> 
> So from my chair, not only is the distinction useful, but scoped access 
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
> 
I don't question your numbers, but it's once again a statistic that has to be 
taken with a grain of salt:
The only claim that is backed by the table is that private is used more often 
in your sample — nothing less, but nothing more.
If private is really more useful, should we remove fileprivate instead?
When you do a survey among car owners how often they have used their airbag, 
and how often the cigar lighter socket, I guess the latter number would be much 
higher — but still, I'd rather keep something that will hopefully never be 
used, but could save my life when it does its job.

Fact is, you can replace every occurrence of "private" with "fileprivate", and 
your source would compile as before, whereas fileprivate saves us from a 
"friend"-keyword.

Afaics, the only real argument for private/fileprivate hasn't been brought up 
at all:
Current private is the only level that can be used to demonstrate access 
control in playgrounds — but I doubt this justifies the confusion caused by it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Adrian Kashivskyy via swift-evolution]

Hi,

> What is your evaluation of the proposal?

+1, I’ve experienced the described problem in my projects.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.

> Does this proposal fit well with the feel and direction of Swift?

Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

I used Swift 2’s and Swift 3’s access modifiers.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I read the proposal and several replies to this thread.

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What
>  goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md Thank you,
>
> -Doug
>
> Review Manager
>
>

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Pranshu Goyal via swift-evolution]

-1

I second Drew Crawford's opinion. Although I agree with some of the
critiques about the current state of access levels in swift, I don't
believe that this would be the right way to proceed.

On 21 March 2017 at 06:56, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> I disagree quite strongly with the proposal.
>
> First, the document draws conclusions without apparent supporting
> evidence, e.g.
>
> > Since the release of Swift 3, the access level change of SE–0025 was met
> with dissatisfaction by a substantial proportion of the general Swift
> community. Those changes can be viewed as actively harmful, the new
> requirement for syntax/API changes.
>
>
>- What is “dissatisfaction by a substantial proportion of the general
>Swift community”? How was this measured/determined?
>- What was done to control for the population happy with SE-0025 who
>would e.g. not be likely to take up pitchforks?
>- Who argues these changes are “actively harmful” and where were they
>during SE-0025?
>
> > subtly encourages overuse of scoped access control and discourages the
> more reasonable default
>
>
>- Who claims that scoped access is “overused” and what is their
>argument for doing so?
>- Why is “fileprivate” the “more reasonable default”? In fact neither
>fileprivate **nor** private are default (reasonable or not!). Internal
>is the default. Nor does this proposal suggest we change that. So this
>seems a very strange statement.
>
> > But is that distinction between private and fileprivate actively used by
> the larger community of Swift developers?
>
> Yes. To cite some evidence, here are codebases I actively maintain:
>
> | codebase   | private # |
> fileprivate # | ratio |
>
> ||--
> -|---|---|
>
> | "M" (proprietary)  | 486   | 249
>   | 2x|
>
> | "N"(proprietary)   | 179   | 59
>| 3x|
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   |
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   |
>
> So from my chair, not only is the distinction useful, but scoped access
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
>
> > And if it were used pervasively, would it be worth the cognitive load
> and complexity of keeping two very similar access levels in the language?
> This proposal argues that answer to both questions is no
>
> This proposal does not make any later argument about “cognitive load” or
> “complexity” I can identify.  Did the proposal get truncated?
>
> What is stated (without evidence) is that "it is extremely common to use
> several extensions within a file” and that use of “private” is annoying in
> that case.  I now extend the above table
>
> | codebase   | private # |
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
>
> ||--
> -|---|---|--
> |
>
> | "M" (proprietary)  | 486   | 249
>   | 2x| 48   |
>
> | "N"(proprietary)   | 179   | 59
>| 3x| 84   |
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   | 3|
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   | 6|
>
> in order to demonstrate in my corner of Swift this is not “extremely
> common”, and is actually less popular than language features the proposal
> alleges aren’t used.
>
> My point here is that ***different people in different corners of the
> community program Swift differently and use different styles***.  I can
> definitely empathize with folks like the author who use extensions to group
> functions and are annoyed that their favorite visibility modifier grew four
> extra characters.  Perhaps we can come up with a keyword that is more
> succint.
>
> However, that is no reason to take away features from working codebases.
> A scoped access modifier is perhaps my favorite feature in Swift 3.  Let’s
> not throw stuff away because it adds extra characters to one programming
> style.
>
> Finally, SE-0025 establishes clear motivation for the scoped access
> modifier:
>
> > Currently, the only reliable way to hide implementation details of a
> class is to put the code in a separate file and mark it as private. This is
> not ideal for the following reasons:
>
> > It is not clear whether the 

[swift-evolution] [Proposal] Add clamp(to:) to the stdlib

[Nicholas Maccharoli via swift-evolution]

​Swift-Evolution,

I propose that `clamp(to:)` be added to the standard library as detailed
in the proposal written below.
There is also an open pull request to the swift-evolution repository open
here:

https://github.com/apple/swift-evolution/pull/641

The idea was discussed on previous threads and a few people helped make
the draft proposal better.
Since the reception of the ​idea was overall good, I thought it might be
worth it
to formally propose the idea.

Please tell me what you think.

- Nick

Add clamp(to:) to the stdlib

   - Proposal: SE-
   

   - Authors: Nicholas Maccharoli 
   - Review Manager: TBD
   - Status: Awaiting review

*During the review process, add the following fields as needed:*

   - Decision Notes: Rationale
   , Additional
   Commentary 
   - Bugs: SR- , SR-
   
   - Previous Revision: 1
   

   - Previous Proposal: SE-
   



Introduction

This proposal aims to add functionality to the standard library for
clamping a value to a provided Range. The proposed function would allow the
user to specify a range to clamp a value to where if the value fell within
the range, the value would be returned as is, if the value being clamped
exceeded the upper or lower bound in value the value of the boundary the
value exceeded would be returned.

Swift-evolution thread: Add a clamp function to Algorithm.swift


Motivation

There have been quite a few times in my professional and personal
programming life where I reached for a function to limit a value to a given
range and was disappointed it was not part of the standard library.

There already exists an extension to CountableRange in the standard library
implementing clamped(to:) that will limit the calling range to that of the
provided range, so having the same functionality but just for types that
conform to the Comparable protocol would be conceptually consistent.

Having functionality like clamped(to:) added to Comparable as a protocol
extension would benefit users of the Swift language who wish to guarantee
that a value is kept within bounds, perhaps one example of this coming in
handy would be to limit the result of some calculation between two
acceptable numerical limits, say the bounds of a coordinate system.
Proposed
solution

The proposed solution is to add a clamped(to:) function to the Swift
Standard Library as an extension to Comparable and Strideable. The function
would return a value within the bounds of the provided range, if the value
clamped(to:) is being called on falls within the provided range then the
original value would be returned. If the value was less or greater than the
bounds of the provided range then the respective lower or upper bound of
the range would be returned.

It does not make sense to call clamped(to:) with an empty range, therefore
calling clamped(to:) and passing an empty range like foo.clamped(to:
0..<0) would
result in a fatal error.

Given a clamped(to:) function existed it could be called in the following
way, yielding the results in the adjacent comments:

let foo = 100
// Closed range variant
foo.clamped(to: 0...50) // 50foo.clamped(to: 200...300) //
200foo.clamped(to: 0...150) // 100// Half-Open range variant
foo.clamped(to: 0..<50) // 49foo.clamped(to: 200..<300) //
200foo.clamped(to: 0..<150) // 100

Detailed
design

The implementation of clamped(to:) that is being proposed is composed of
two protocol extensions; one protocol extension on Comparable and another
on Strideable.

The implementation for clamped(to:) as an extension to Comparable accepting
a range of type ClosedRangewould look like the following:

extension Comparable {
func clamped(to range: ClosedRange) -> Self {
if self > range.upperBound {
return range.upperBound
} else if self < range.lowerBound {
return 

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

[Brent Royal-Gordon via swift-evolution]

> On Mar 20, 2017, at 9:12 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> If a character had to be used to denote key paths then I would prefer this 
> one:
> 
> 1. Type:path.to.value and instance:path.to.value
> 
> I feel like the # screams at me. :-)


If I write `foo[instance:path.to.value]`, how is Swift to know whether that's a 
key path or an argument label?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 21 Mar 2017, at 10:15, Jonathan Hull via swift-evolution 
>  wrote:

+1

Big Yes, collect the other stuff on access levels and modules too before 
implementing anything.

> 
> I wonder if there is a way to basically accept that this is what we want to 
> do, but delay implementing it until we have other changes to make to the 
> access system (e.g. submodules) at the same time?
> 
> If things like that are scoped for Swift 5, then I would say delay 
> implementing this until then.  If it will be longer than that, we may as well 
> fix it now.
> 
> 
>> On Mar 21, 2017, at 2:07 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal link:
>>> 
 https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I'm torn. During the SE-0025 review, I argued against scoped private. I 
>> still think it was a mistake to add it. But we did, it's out there, and I 
>> don't want to introduce churn unnecessarily.
>> 
>> Long ago, judges realized the problems caused by re-litigating old disputes 
>> and created a doctrine called "stare decisis": standing by things decided. 
>> That doesn't mean they won't correct obvious mistakes, but it does mean that 
>> they default to upholding the precedent they've already set. I think that 
>> would be a wise course here.
>> 
>> I personally would prefer to have Swift behave as SE-0159 proposes. But if 
>> the core team thinks this is going to come out 50/50—that is, this change 
>> will help about as many people as it hurts—I think they should reject this 
>> proposal and keep the status quo. I really don't want to write another 
>> review next year for SE-0289 "Reintroduce Scoped Private".
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

I wonder if there is a way to basically accept that this is what we want to do, 
but delay implementing it until we have other changes to make to the access 
system (e.g. submodules) at the same time?

If things like that are scoped for Swift 5, then I would say delay implementing 
this until then.  If it will be longer than that, we may as well fix it now.


> On Mar 21, 2017, at 2:07 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Proposal link:
>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> 
>>  • What is your evaluation of the proposal?
> 
> I'm torn. During the SE-0025 review, I argued against scoped private. I still 
> think it was a mistake to add it. But we did, it's out there, and I don't 
> want to introduce churn unnecessarily.
> 
> Long ago, judges realized the problems caused by re-litigating old disputes 
> and created a doctrine called "stare decisis": standing by things decided. 
> That doesn't mean they won't correct obvious mistakes, but it does mean that 
> they default to upholding the precedent they've already set. I think that 
> would be a wise course here.
> 
> I personally would prefer to have Swift behave as SE-0159 proposes. But if 
> the core team thinks this is going to come out 50/50—that is, this change 
> will help about as many people as it hurts—I think they should reject this 
> proposal and keep the status quo. I really don't want to write another review 
> next year for SE-0289 "Reintroduce Scoped Private".
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal link:
> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> 
>   • What is your evaluation of the proposal?

I'm torn. During the SE-0025 review, I argued against scoped private. I still 
think it was a mistake to add it. But we did, it's out there, and I don't want 
to introduce churn unnecessarily.

Long ago, judges realized the problems caused by re-litigating old disputes and 
created a doctrine called "stare decisis": standing by things decided. That 
doesn't mean they won't correct obvious mistakes, but it does mean that they 
default to upholding the precedent they've already set. I think that would be a 
wise course here.

I personally would prefer to have Swift behave as SE-0159 proposes. But if the 
core team thinks this is going to come out 50/50—that is, this change will help 
about as many people as it hurts—I think they should reject this proposal and 
keep the status quo. I really don't want to write another review next year for 
SE-0289 "Reintroduce Scoped Private".

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 20, 2017, at 8:26 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> the concern with extensions could be easily solved simply by giving 
> extensions access to private members of the extended type as long as those 
> extensions are in the same module/submodule (or file, if you prefer, but I 
> don’t). This would probably eliminate almost all of the use cases for 
> fileprivate, as well as freeing us from the sometimes clumsy situation where 
> we’re rather artificially forced to use files as a scope, instead enabling us 
> to organize code into files as is appropriate for the project.


I think that many advocates of scoped private misunderstand critics' concerns 
about extensions.

One of the nice things about file-based `private` is that it allows access from 
extensions not only on the same type, but also on *other* types. For example, 
suppose I have a Book type and I want to allow them to be added to bookshelves:

class Bookshelf {
// I'm using file-based private here
private(set) var books: [Book]

func addBook(_ book: Book) {
book.bookshelf = self
books.append(book)
}
}

I also want to have a removal method, but—much like `UIView` and `NSView`'s 
`removeFromSuperivew`—I want that method to be on `Book`, not `Bookshelf`. With 
file-based private, that's no problem—just drop the code in an extension in the 
same file:

extension Book {
func removeFromBookshelf() {
guard let shelf = bookshelf else { return }
shelf.remove(at: shelf.books.index(of: self)!)
bookshelf = nil
}
}

When we talk about file-based private being "better for extensions", we're 
*not*—or at least not necessarily—talking about it being better for the pattern 
of splitting a type into several different extensions to group related code 
together. We're talking about the pattern of splitting a *concern* across 
several different *types* by extending all of them, taking advantage of Swift's 
flexible scoping to encapsulate details even when the type hierarchy doesn't 
match the encapsulation boundaries you want.

So allowing `private` members to be seen by extensions anywhere in a project 
doesn't address this issue; in fact, it actively and aggressively undermines 
it, making it impossible to encapsulate any implementation details at a scope 
smaller than a single type. For myself and others like me, it is the exact 
opposite of what we want.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Howard Lovatt via swift-evolution]

The review of SE-0159 "Fix Private Access Levels"

> What is your evaluation of the proposal?

Great idea too fiddly and fussy for my liking. Preferred the original meaning 
of private. 

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Probably 

> Does this proposal fit well with the feel and direction of Swift?
Yes, keep it simple 

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Yes Swift 1!

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Have been caught out typing private and then wanting to implement an interfaces 
methods in an extension. 

-- Howard. 

> On 21 Mar 2017, at 10:54 am, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 21 Mar 2017, at 08:55, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 07:05, Rien via swift-evolution 
>>  wrote:
>> 
>> +1
>> 
>>>   • What is your evaluation of the proposal?
>> 
>> Makes the language easier to understand, lowers cognitive load during coding.
> 
> Is it really a problem for cognitive load during coding? In a world where 
> protocol extensions defined default methods introducing back the nice and 
> easy to understand concept of polymorphism by reference type where casting an 
> instances class that overrides the method declared in the protocol extensions 
> decides which  method is actually executed... well, having to juggle file and 
> scope based access levels breaks the camel's back?

It does not break the camel’s back, but it does lower the load.
I fully well realize that this issue is not a big one and highly personal, and 
if “fileprivate” remains in use, well, I won’t give up on Swift ;-)

> 
> I remain unconvinced of this, no offense meant Rien.

None taken

Regards,
Rien.

> 
>> I also hope this will pave the way for a overhaul of the access level system 
>> including modularization.
>> 
>>>   • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> yes.
>> 
>>>   • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes
>> 
>>>   • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> private vs fileprivate seems swift-only, as such I have no comparison.
>> 
>>>   • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> Followed and participated in the discussions.
>> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. When replying, please try to keep the proposal link at the top of 
>>> the message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>> Reply text
>>> Other replies
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>>   • What is your evaluation of the proposal?
>>>   • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>>   • Does this proposal fit well with the feel and direction of Swift?
>>>   • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>>   • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> Thank you,
>>> 
>>> -Doug
>>> 
>>> Review Manager
>>> 
>>> ___
>>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charlie Monroe via swift-evolution]

> On Mar 21, 2017, at 8:26 AM, Slava Pestov  wrote:
> 
>> 
>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> -1 on this as well for similar reasons. Places where I use fileprivate 
>> (aside from what was automatically migrated by Xcode) can be counted on 
>> fingers of one or two hands. 
>> 
>> I feel that this proposal is reverting something without offering an 
>> alternative solution.
> 
> In what situations do you use Swift 3 private where fileprivate is not an 
> acceptable replacement?

In my usage, I very rarely use fileprivate. To back this with numbers, a recent 
project I developed (i.e. without Xcode's automatic migration of private -> 
fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses of "private".

This is definitely a personal opinion, but I tend to limit access to members as 
much as possible to discourage/prevent their usage out of the scope they are 
intended for and to better design API that should be used out of the scope 
(public/internal). I feel this is a good thing for newcomers to a codebase (and 
myself coming back to a codebase after a year or two) as Xcode's autocompletion 
won't offer members that are not supposed to be called out of the scope 
(scope-private). 

As I've mentioned this during the discussion, I feel that current state of 
things encourages huge files (1000+ lines of code) as you can't define 
"protected" level access and migrate some of the code that implements e.g. 
accessibility to a different file without potentially exposing internal details 
to the rest of the module (if the extension in the other file needs access to 
private details, which is often the case).

I feel that if there should be a change to the access levels, it should address 
this as well. The current solution based on reverting the original proposal 
only unnecessarily exposes implementational details to the rest of the file - 
at least in my codebase.

> 
> Slava
> 
>> 
>>> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 20, 2017, at 4:54 PM, Douglas Gregor > wrote:
 
 Hello Swift community,
 
 The review of SE-0159 "Fix Private Access Levels" begins now and runs 
 through March 27, 2017. The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
  
 
>>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>>> explained my concerns.
>>> 
>>> 
>>> -- 
>>> Greg Parker gpar...@apple.com  Runtime 
>>> Wrangler
>>> 
>>> 
>>> ___
>>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Forgot to cc.

Sent from my iPhone

> On 21 Mar 2017, at 07:43, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 02:33, Greg Parker via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> 
>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>> explained my concerns.
>> 
> 
> -1 here as well, fully support Drew Crawford's points too. 
> 
> To add my own 2c to it, I would say better time would be spent gathering data 
> on number of bugs, severity, performance and more correlated to the (growing) 
> use of Swift for example rather than just vocally discuss what is Swifty and 
> what is not, talk about safety by default and performance to drive our 
> community decisions without tracking those kpi's (data driven decisions). As 
> much as it could be improved, Mozilla's AreWeFastYet.org's project is a 
> direction we could explore.
> 
> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 07:05, Rien via swift-evolution 
>  wrote:
> 
> +1
> 
>>• What is your evaluation of the proposal?
> 
> Makes the language easier to understand, lowers cognitive load during coding.

Is it really a problem for cognitive load during coding? In a world where 
protocol extensions defined default methods introducing back the nice and easy 
to understand concept of polymorphism by reference type where casting an 
instances class that overrides the method declared in the protocol extensions 
decides which  method is actually executed... well, having to juggle file and 
scope based access levels breaks the camel's back?

I remain unconvinced of this, no offense meant Rien.

> I also hope this will pave the way for a overhaul of the access level system 
> including modularization.
> 
>>• Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> yes.
> 
>>• Does this proposal fit well with the feel and direction of Swift?
> 
> Yes
> 
>>• If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> private vs fileprivate seems swift-only, as such I have no comparison.
> 
>>• How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Followed and participated in the discussions.
> 
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>• What is your evaluation of the proposal?
>>• Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>• Does this proposal fit well with the feel and direction of Swift?
>>• If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>• How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Charles Srstka's added comment, while intriguing, poses a problem in 
>> argumentation. One of the points being made above about the major advantage 
>> of new `private` over `fileprivate` is precisely that new `private` is 
>> invisible to extensions. If one "solves" the problem of having to use 
>> `fileprivate` by making `private` visible to extensions, it may well be the 
>> case that `fileprivate` is no longer commonly necessary--but one has also 
>> reverted one of the major arguments in favor of new `private` in the first 
>> place.
> 
> I don’t see making things invisible to extensions to be the benefit of 
> ‘private’ at all—it’s for maintaining encapsulation with embedded types. i.e. 
> things like this:
> 
> class Foo {
>   class Bar {
>   private var baz: String // <— ‘Foo’ doesn’t need to access this
>   }
> }
> 
> This just enforces good programming style.

I cannot believe this proposal is putting scoped access' value into question 
sigh (not you, you are making a point supporting it obviously :)).


> On the other hand, the problem with extensions that people are talking about 
> comes from using extensions to separate sections of a type’s built-in code, 
> mainly around protocol conformances:
> 
> class Foo {
>   private var bar: String
> }
> 
> extension Foo: Baz {
>   func requiredByBaz() {
>   doSomething(with: self.bar) // <— ruh roh
>   }
> }
> 
> The way I look at it, the extension feature was created with the idea of 
> extending someone else’s type in mind, but the community latched onto it as a 
> way to organize the parts of your own type, and Swift 3’s ‘private’ is 
> getting in the way of that. Broadening ‘private’ to reach in-module 
> extensions would solve this issue, and would *also* allow flexibility to, 
> when the code for an extension gets significantly large relative to the rest 
> of the type's code, split that part off into a different file without needing 
> to make your internal state visible to the entire module. Kill two birds with 
> one stone, so to speak.
> 
> Charles
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

> On 21 Mar 2017, at 02:26, Drew Crawford via swift-evolution 
>  wrote:
> 
> I disagree quite strongly with the proposal.
> 
> First, the document draws conclusions without apparent supporting evidence, 
> e.g.
> 
> > Since the release of Swift 3, the access level change of SE–0025 was met 
> > with dissatisfaction by a substantial proportion of the general Swift 
> > community. Those changes can be viewed as actively harmful, the new 
> > requirement for syntax/API changes.
> What is “dissatisfaction by a substantial proportion of the general Swift 
> community”? How was this measured/determined?
> What was done to control for the population happy with SE-0025 who would e.g. 
> not be likely to take up pitchforks?
> Who argues these changes are “actively harmful” and where were they during 
> SE-0025?
> > subtly encourages overuse of scoped access control and discourages the more 
> > reasonable default
> Who claims that scoped access is “overused” and what is their argument for 
> doing so?
> Why is “fileprivate” the “more reasonable default”? In fact neither 
> fileprivate *nor* private are default (reasonable or not!). Internal is the 
> default. Nor does this proposal suggest we change that. So this seems a very 
> strange statement.
> > But is that distinction between private and fileprivate actively used by 
> > the larger community of Swift developers?
> Yes. To cite some evidence, here are codebases I actively maintain:
> 
> | codebase   | private # | 
> fileprivate # | ratio |
> 
> ||---|---|---|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x|
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x|
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1  
>| 15x   |
> 
> | atbuild https://github.com/AnarchyTools/atbuild | 54| 5 
> | 11x   |
> 
> So from my chair, not only is the distinction useful, but scoped access 
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
> 
> > And if it were used pervasively, would it be worth the cognitive load and 
> > complexity of keeping two very similar access levels in the language? This 
> > proposal argues that answer to both questions is no
> 
> This proposal does not make any later argument about “cognitive load” or 
> “complexity” I can identify.  Did the proposal get truncated?
> 
> What is stated (without evidence) is that "it is extremely common to use 
> several extensions within a file” and that use of “private” is annoying in 
> that case.  I now extend the above table
> 
> | codebase   | private # | 
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
> 
> ||---|---|---|--|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x| 48   |
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x| 84   |
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1  
>| 15x   | 3|
> 
> | atbuild https://github.com/AnarchyTools/atbuild | 54| 5 
> | 11x   | 6|
> 
> in order to demonstrate in my corner of Swift this is not “extremely common”, 
> and is actually less popular than language features the proposal alleges 
> aren’t used.
> 
> My point here is that **different people in different corners of the 
> community program Swift differently and use different styles**.  I can 
> definitely empathize with folks like the author who use extensions to group 
> functions and are annoyed that their favorite visibility modifier grew four 
> extra characters.  Perhaps we can come up with a keyword that is more succint.
> 
> However, that is no reason to take away features from working codebases.  A 
> scoped access modifier is perhaps my favorite feature in Swift 3.  Let’s not 
> throw stuff away because it adds extra characters to one programming style.
> 
> Finally, SE-0025 establishes clear motivation for the scoped access modifier:
> 
> > Currently, the only reliable way to hide implementation details of a class 
> > is to put the code in a separate file and mark it as private. This is not 
> > ideal for the following reasons:
> 
> > It is not clear whether the implementation details are meant to be 
> > completely hidden or can be shared with some related code without the 
> > danger of misusing the APIs marked as private. If a file already has 
> > multiple 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Slava Pestov via swift-evolution]

> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> -1 on this as well for similar reasons. Places where I use fileprivate (aside 
> from what was automatically migrated by Xcode) can be counted on fingers of 
> one or two hands. 
> 
> I feel that this proposal is reverting something without offering an 
> alternative solution.

In what situations do you use Swift 3 private where fileprivate is not an 
acceptable replacement?

Slava

> 
>> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>>> through March 27, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>>  
>>> 
>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>> explained my concerns.
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com  Runtime 
>> Wrangler
>> 
>> 
>> ___
>> 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] [Proposal] Foundation Swift Archival & Serialization

[Brent Royal-Gordon via swift-evolution]

> On Mar 20, 2017, at 12:31 PM, Itai Ferber  wrote:
> 
> I don’t think there’s much of a difference between adding an "optional" 
> primitive (which has a default implementation in terms of a different 
> primitive) and simply having that type adopt Codable itself and not be a 
> primitive. You can still switch on the type dynamically (and we do), but you 
> don’t need the optional overload for it.

There's an important exception to that: You can't switch on a protocol which 
has associated types, like BinaryInteger or FloatingPoint.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

+1

>   • What is your evaluation of the proposal?

Makes the language easier to understand, lowers cognitive load during coding.
I also hope this will pave the way for a overhaul of the access level system 
including modularization.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

yes.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

private vs fileprivate seems swift-only, as such I have no comparison.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed and participated in the discussions.


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?
>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   • Does this proposal fit well with the feel and direction of Swift?
>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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] [Proposal] Factory Initializers

[Rien via swift-evolution]

I just have to ask: why should a factory method be part of the language?

I have nothing against it, I am just wondering if I am missing something.
The way I see it everyone can add a factory initializer if he/she needs it. Why 
make it part of the language?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 20 Mar 2017, at 21:40, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Huge +1
> 
> 
>> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution 
>>  wrote:
>> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> Recently, I proposed the idea of adding the ability to implement the 
> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
> discussed it and came up with different approaches, it evolved into a 
> functionality that I believe is far more beneficial to Swift, and 
> subsequently should be the focus of its own proposal. So here is the 
> improved (pre-)proposal:
> 
> # Factory Initializers
> 
> The "factory" pattern is common in many languages, including Objective-C. 
> Essentially, instead of initializing a type directly, a method is called 
> that returns an instance of the appropriate type determined by the input 
> parameters. Functionally this works well, but ultimately it forces the 
> client of the API to remember to call the factory method instead, rather 
> than the type's initializer. This might seem like a minor gripe, but 
> given that we want Swift to be as approachable as possible to new 
> developers, I think we can do better in this regard.
> 
> Rather than have a separate factory method, I propose we build the 
> factory pattern right into Swift, by way of specialized “factory 
> initializers”. The exact syntax was proposed by Philippe Hausler from the 
> previous thread, and I think it is an excellent solution:
> 
> class AbstractBase {
>  public factory init(type: InformationToSwitchOn) {
>  return ConcreteImplementation(type)
>  }
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> Why exactly would this be useful in practice? In my own development, I’ve 
> come across a few places where this would especially be relevant:
> 
> ## Class Cluster/Abstract Classes
> This was the reasoning behind the original proposal, and I still think it 
> would be a very valid use case. The public superclass would declare all 
> the public methods, and could delegate off the specific implementations 
> to the private subclasses. Alternatively, this method could be used as an 
> easy way to handle backwards-compatibility: rather than litter the code 
> with branches depending on the OS version, simply return the 
> OS-appropriate subclass from the factory initializer. Very useful.
> 
> ## Protocol Initializers
> Proposed by Brent Royal-Gordon, we could use factory initializers with 
> protocol extensions to return the appropriate instance 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 12:48 AM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Charles Srstka's added comment, while intriguing, poses a problem in
> argumentation. One of the points being made above about the major advantage
> of new `private` over `fileprivate` is precisely that new `private` is
> invisible to extensions. If one "solves" the problem of having to use
> `fileprivate` by making `private` visible to extensions, it may well be the
> case that `fileprivate` is no longer commonly necessary--but one has also
> reverted one of the major arguments in favor of new `private` in the first
> place.
>
>
> I don’t see making things invisible to extensions to be the benefit of
> ‘private’ at all
>

This feature of new `private` is literally one of the two headline goals
outlined in the proposal as it was approved. SE-0025 has written it into
the opening sentence: "Scoped access level allows hiding implementation
details of a class or a class extension at the class/extension level,
instead of a file." It is absolutely an intended benefit of new `private`.
That's just a factual statement.


> —it’s for maintaining encapsulation with embedded types. i.e. things like
> this:
>
> class Foo {
> class Bar {
> private var baz: String // <— ‘Foo’ doesn’t need to access this
> }
> }
>
> This just enforces good programming style. On the other hand, the problem
> with extensions that people are talking about comes from using extensions
> to separate sections of a type’s built-in code, mainly around protocol
> conformances:
>
> class Foo {
> private var bar: String
> }
>
> extension Foo: Baz {
> func requiredByBaz() {
> doSomething(with: self.bar) // <— ruh roh
> }
> }
>
> The way I look at it, the extension feature was created with the idea of
> extending someone else’s type in mind, but the community latched onto it as
> a way to organize the parts of your own type, and Swift 3’s ‘private’ is
> getting in the way of that. Broadening ‘private’ to reach in-module
> extensions would solve this issue, and would *also* allow flexibility to,
> when the code for an extension gets significantly large relative to the
> rest of the type's code, split that part off into a different file without
> needing to make your internal state visible to the entire module. Kill two
> birds with one stone, so to speak.
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charlie Monroe via swift-evolution]

-1 on this as well for similar reasons. Places where I use fileprivate (aside 
from what was automatically migrated by Xcode) can be counted on fingers of one 
or two hands. 

I feel that this proposal is reverting something without offering an 
alternative solution.

> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> through March 27, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>>  
>> 
> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
> explained my concerns.
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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