Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

[Rien via swift-evolution]

I subscribed to the list, thanks.

I guess security is something people “want to look into later”… and then 
somehow never get to it.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 06 Apr 2017, at 23:04, Gelareh Taban  wrote:
> 
> Hi Rien,
> 
> This is great, thanks for referencing your blogs/repo. I'll go through them.
> (An unfortunate issue I have found with security is that, we need it, we 
> expect it, but we don't want to worry about it :-)
> 
> The basic structure of what we are considering right now would to a large 
> extent follow that of 
> https://github.com/IBM-Swift/BlueSSLService/
> which invokes SecureTransport on Apple and OpenSSL on Linux. 
> 
> For more details of some of the discussions, just follow this thread.
> https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000298.html
> 
> Would love to have your contributions here! :-D
> 
> gelareh
> 
> 
> 
> 
> Rien ---04/06/2017 11:54:57 AM---Having just finished a 
> client/server framework that builds on openSSL I sympathise with this proposa
> 
> From: Rien 
> To: Gelareh Taban/Austin/IBM@IBMUS
> Cc: swift-evolution@swift.org
> Date: 04/06/2017 11:54 AM
> Subject: Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library
> 
> 
> 
> 
> Having just finished a client/server framework that builds on openSSL I 
> sympathise with this proposal.
> 
> However, I wrote a few blogposts about my experiences with openSSL. And those 
> leads me to believe that there is not much interest in secure networking. The 
> number of hits on those posts are quite low (anaemic even) when compared to 
> -for example- posts on socket programming.
> 
> While the sketch you made below does not sound too bad, I am afraid that the 
> API will become complex so fast, that it will not be much easier to use than 
> openSSL/LibreSSL etc. But don’t let that stop you ;-)
> 
> Regards,
> Rien
> 
> PS: https://github.com/Balancingrock/SecureSockets
> 
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - A server for websites build in Swift
> 
> 
> 
> 
> 
> 
> > On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution 
> >  wrote:
> > 
> > Hi all,
> > 
> > I’d like to pitch some of the ideas that have been discussed in the server 
> > working group around security. 
> > 
> > To get more information on the server API group and its goals, see 
> > https://swift.org/server-apis/. (TL;DR version is to come up with a set of 
> > foundational APIs that work cross-platform, on all platforms supported by 
> > Swift, including Linux.) 
> > 
> > For security, we have divided the scope into SSL/TLS support and crypto 
> > support. Our first goal and the subject of this pitch is TLS. This current 
> > pitch is the result of various discussions that have taken place over the 
> > past several months over the server working group mailing list and several 
> > projects by groups such as Vapor, IBM, Zewo, etc. 
> > 
> > Our plan is to start with the main ideas presented here and work on a Swift 
> > library that we prototype and iterate on before finalizing on a specific 
> > interface. Hopefully the ideas in this pitch are non-controversial, aside 
> > from the naming of the method and protocols (which is widely accepted as a 
> > `hard` problem).
> > 
> > # Problem
> > 
> > Since there is currently no standard Swift SSL/TLS library that is 
> > compatible on both Apple and Linux, Swift projects use their TLS library of 
> > choice (such as OpenSSL, LibreSSL, Security framework, etc). This results 
> > in:
> > - fragmentation of the space as well as incompatibility of project 
> > dependencies if more than one security package is needed by different 
> > modules (a project cannot have both OpenSSL and LibreSSL in its dependency 
> > graph)
> > - insecurity (using an unpatched or deprecated library such as OpenSSL on 
> > macOS)
> > - unmaintainablity (using non-standard or non-native libraries)
> > - more complex code (using different APIs or code paths for each platform).
> > 
> > So we want to propose a standard set of protocols that define the behavior 
> > of the TLS service and how the application and the server and networking 
> > layers beneath it interact with the TLS service. What complicates this 
> > pitch is that the Swift in server space is new and none of the interfaces 
> > have yet been defined, so this is really a work in iteration.
> > 
> > # Design goals
> > 
> > We came up with the following design goals for a solution:
> > 
> > - Provide a consistent and unified Swift interface so that the developer 
> > can write simple, cross-platform applications;
> > - Don't implement new crypto functionality and instead use existing 
> > 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charlie Monroe via swift-evolution]

-1 for reasons I've previously expressed in the discussions:

- It encourages everything to be stuffed in one file.
- It doesn't actually solve anything as the new private is very close to 
fileprivate, while abolishing private as truly scoped - which is a tool I use 
on regular basis.

Simply as long as it's file-based, it's not a solution, it's just another 
attempt to satisfy some part of the community. I'm not saying that the current 
access levels are perfect, but I still believe the way to go is to either use 
submodules, and/or introducing the concept of "protected" members.

> On Apr 7, 2017, at 1:10 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 9:46 PM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
>>> On Apr 6, 2017, at 20:37 , John McCall  wrote:
>>> 
 On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
  wrote:
 I tend to dislike the backslash as well, but can't suggest a good 
 alternative.
 
 Does any of this allow for operations within the key path? e.g. 
 Department.employees.@sum.salary?
>>> 
>>> You can express things like this in the feature as proposed using 
>>> subscripts:
>>> 
>>> extension Collection {
>>> subscript(summing path: KeyPath) -> T {
>>>  var sum: T = 0
>>>  for let elt in self {
>>>sum += elt[keyPath: path]
>>>  }
>>>  return sum
>>> }
>>> }
>> 
>> I'm just remembering how AppKit/Cocoa lets you do things like this in a very 
>> expressive way. Your proposal seems a bit cumbersome. Maybe when we have 
>> custom annotations, they can be extended to use within key paths.
> 
> I'm not seriously endorsing this exact spelling.  It would be much better to 
> be able to write something like:
>  \Department.employees.sum(of: \.salary)
> However, since "sum" would presumably be a method on Collection, I think this 
> would have to be a future extension to the proposal, and the overall thing 
> might have to be a function rather than a key path because it would no longer 
> have identity.

Also, less clever but potentially easier to reason about:

extension Array where Element == Employee {
  var sumOfSalary: Double {
return // ...
  }
}

If you can express it in a computed property, you can refer to it via a key 
path:

\Department.employees.sumOfSalary



> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of 
> doing this is a small number of hard-coded operators, whereas even the 
> kindof-unfortunate subscript trick would be arbitrarily extensible.

Right.

- Doug

> John.
> 
> 
>> 
>> Thanks.
>> 
>>> 
>>> ...
>>> 
>>> \Department.employees[summing: \.salary]
>>> 
>>> That's not actually a good name for the subscript, but maybe there's one 
>>> out there.
>>> 
>>> John.
>>> 
 
 Also, in this example:
 
 let firstFriendsNameKeyPath = \Person.friends[0].name
 let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
 
 Can't we do without the keyPath: argument name? The compiler knows it's a 
 keypath, it would be nicer to write
 
 let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
 
> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be 
> viewed at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> 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/0161-key-paths.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
> 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 7, 2017, at 12:27 AM, Rick Mann  wrote:
>> On Apr 6, 2017, at 20:37 , John McCall  wrote:
>> 
>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>>  wrote:
>>> I tend to dislike the backslash as well, but can't suggest a good 
>>> alternative.
>>> 
>>> Does any of this allow for operations within the key path? e.g. 
>>> Department.employees.@sum.salary?
>> 
>> You can express things like this in the feature as proposed using subscripts:
>> 
>> extension Collection {
>> subscript(summing path: KeyPath) -> T {
>>   var sum: T = 0
>>   for let elt in self {
>> sum += elt[keyPath: path]
>>   }
>>   return sum
>> }
>> }
> 
> I'm just remembering how AppKit/Cocoa lets you do things like this in a very 
> expressive way. Your proposal seems a bit cumbersome. Maybe when we have 
> custom annotations, they can be extended to use within key paths.

I'm not seriously endorsing this exact spelling.  It would be much better to be 
able to write something like:
  \Department.employees.sum(of: \.salary)
However, since "sum" would presumably be a method on Collection, I think this 
would have to be a future extension to the proposal, and the overall thing 
might have to be a function rather than a key path because it would no longer 
have identity.

Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of 
doing this is a small number of hard-coded operators, whereas even the 
kindof-unfortunate subscript trick would be arbitrarily extensible.

John.


> 
> Thanks.
> 
>> 
>> ...
>> 
>> \Department.employees[summing: \.salary]
>> 
>> That's not actually a good name for the subscript, but maybe there's one out 
>> there.
>> 
>> John.
>> 
>>> 
>>> Also, in this example:
>>> 
>>> let firstFriendsNameKeyPath = \Person.friends[0].name
>>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>> 
>>> Can't we do without the keyPath: argument name? The compiler knows it's a 
>>> keypath, it would be nicer to write
>>> 
>>> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
>>> 
 On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
  wrote:
 
 Hello Swift community,
 
 The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
 Swift" begins now and runs through April 9, 2017. The revised proposal is 
 available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
 The core team’s feedback from the first review of this proposal can be 
 viewed at:
 
 https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
 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/0161-key-paths.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
>>> 
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charlie Monroe via swift-evolution]

> On Apr 7, 2017, at 2:38 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.
> 
> Who is currently doing that?
> 
> Charles

On many occasions. If you have an extension that is a UITableViewDataSource, 
you may want private methods that prepare the cell, etc. Maybe not the most 
convincing example, but yes, there are such cases.

> 
> ___
> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Rick Mann via swift-evolution]

> On Apr 6, 2017, at 20:37 , John McCall  wrote:
> 
>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>  wrote:
>> I tend to dislike the backslash as well, but can't suggest a good 
>> alternative.
>> 
>> Does any of this allow for operations within the key path? e.g. 
>> Department.employees.@sum.salary?
> 
> You can express things like this in the feature as proposed using subscripts:
> 
> extension Collection {
>  subscript(summing path: KeyPath) -> T {
>var sum: T = 0
>for let elt in self {
>  sum += elt[keyPath: path]
>}
>return sum
>  }
> }

I'm just remembering how AppKit/Cocoa lets you do things like this in a very 
expressive way. Your proposal seems a bit cumbersome. Maybe when we have custom 
annotations, they can be extended to use within key paths.

Thanks.

> 
> ...
> 
> \Department.employees[summing: \.salary]
> 
> That's not actually a good name for the subscript, but maybe there's one out 
> there.
> 
> John.
> 
>> 
>> Also, in this example:
>> 
>> let firstFriendsNameKeyPath = \Person.friends[0].name
>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>> 
>> Can't we do without the keyPath: argument name? The compiler knows it's a 
>> keypath, it would be nicer to write
>> 
>> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
>> 
>>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>>> available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>> The core team’s feedback from the first review of this proposal can be 
>>> viewed at:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>>> 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/0161-key-paths.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
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 5, 2017, at 7:56 PM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

Something came to mind that I wanted to record, even though it's not directly 
addressed by this proposal.

I know that one future direction here is that key paths ought to be equatable, 
serializable, etc.  Serialization in particular is something that we're going 
to have to think about very carefully.

In general, it's really bad for deserialization to be able to call arbitrary 
code in the program.  There is a well-known security hole in various reflective 
deserialization libraries where they will happily call arbitrary functions or 
constructors if they're named in the serialized data.  (Often, there's some way 
to limit this, but you have to know to use it — so it's merely the default that 
isn't secure, but that's no defense.)  A Swift serialization library would 
hopefully be designed around a protocol that provided a (throwing) 
deserializing initializer, so that (1) types have to opt in to supporting 
deserialization and (2) deserialization doesn't call completely arbitrary code. 
 But it's still a potential security hole if deserialization can construct a 
key path that, when accessed, will execute arbitrary code in the process.

There are other concerns as well.  It's a code-size and performance problem if 
we have to treat every property and subscript in the program as potentially 
used, and emit key-path metadata for them, just in case they might be used by a 
deserialized key path.  And, of course, it potentially becomes a binary 
compatibility problem to remove a property or subscript, even a private one, if 
that was ever used in a key path that was serialized.  But the biggest concern 
is security.

Anyway, just a thought that shouldn't be allowed to derail this proposal.

John.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Michel Fortin via swift-evolution]

> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

> What is your evaluation of the proposal?

I don't understand the need for this: when you need things to be accessible 
elsewhere in the file you can already use `fileprivate`. To me it looks like we 
are trying to change the semantics of `private` to be closer to `fileprivate` 
simply because `fileprivate` has been labeled as an undesirable.

The motivation section of the proposal talks about "the prevalence of 
fileprivate" as if that was a horrendous thing. I disagree with this implicit 
assertion and I will claim that `fileprivate` actually makes a better soft 
default.

I happen to also disagree that this is a narrow change. It's true that in some 
files (those with no extensions) this will have absolutely zero impact; in many 
others (those made of a type and dozen of extensions to that same type) it'll 
make `private` equivalent to `fileprivate`. While it can be narrow in some 
cases, in others it is effectively quite similar to getting rid of `private`. 
SE-0159 was rejected because it removed scoped-private and this is not much 
different.

In the end, this change might achieve the goal of making `fileprivate` used 
less often, but only because `private` becomes very close to `fileprivate` in 
the common case of having a type defined with many extensions as part of the 
same file. I doubt the small difference between `fileprivate` and `private` 
that would remain is enough to justify having two access levels. If we were 
designing from scratch, we'd only keep one of the two and get rid of the other 
as mostly redundant.


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

I think there is a significant problem with access control, but it is ill 
defined. There is nothing inherently wrong with the prevalence of `fileprivate` 
(other than how it's called).


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

I have to admit I find it hard to decipher "the direction of Swift" when it 
comes to access control since SE-0025. My own direction of Swift now is that I 
try to use `fileprivate` instead of `private` unless there is a good reason to 
use `private`. Even though it looks a bit strange at first glance, it has the 
semantics I generally want.

This proposal might make using `private` work in more cases, so I should be 
thrilled, right? I'm not that thrilled because with the semantics being closer 
to `fileprivate` it'll become less obvious which one should be used in which 
situations.


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

Not sure there's anything left to compare to at this point.


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

Read most messages on this topic on the list and replied occasionally.


-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>  wrote:
> I tend to dislike the backslash as well, but can't suggest a good alternative.
> 
> Does any of this allow for operations within the key path? e.g. 
> Department.employees.@sum.salary?

You can express things like this in the feature as proposed using subscripts:

extension Collection {
  subscript(summing path: KeyPath) -> T {
var sum: T = 0
for let elt in self {
  sum += elt[keyPath: path]
}
return sum
  }
}

...

\Department.employees[summing: \.salary]

That's not actually a good name for the subscript, but maybe there's one out 
there.

John.

> 
> Also, in this example:
> 
> let firstFriendsNameKeyPath = \Person.friends[0].name
> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
> 
> Can't we do without the keyPath: argument name? The compiler knows it's a 
> keypath, it would be nicer to write
> 
> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
> 
>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>> The core team’s feedback from the first review of this proposal can be 
>> viewed at:
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>> 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/0161-key-paths.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
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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-0169: Improve Interaction Between private Declarations and Extensions

[Daniel Duan via swift-evolution]

This use case has at least been brought up in discussions within my team. I 
wouldn't be surprised if it's actually deployed as well. Given a big project 
with enough experienced devs, I'd say this pattern is almost a certainty.

Daniel Duan
Sent from my iPhone

> On Apr 6, 2017, at 6:53 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution 
>>>  wrote:
>>> 
>>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> `private` works for extensions exactly how the authors of SE-0025 intended 
>>> it to do. Your comments do not address what would happen for those people 
>>> who are making use of this functionality currently to isolate methods to 
>>> the extension only.
>> 
>> Who is currently doing that?
> 
> Me.
> 
> Even though I think we were better off without scoped `private`, I *have* 
> used it fruitfully on several occasions. These were typically in places where 
> I wanted to restrict access to a small number of members which I could ensure 
> would enforce certain invariants. An example I gave previously involved two 
> arrays which contained matching elements; code should never insert or remove 
> from one array without doing the same to the other. By making these arrays 
> `private` and exposing `fileprivate` and `public` members derived from them, 
> I could ensure that only a couple dozen lines could possibly contain such a 
> bug without changing the external design of the type or introducing 
> boilerplate.
> 
> This proposal does not offer the same utility. The only way to protect 
> fragile parts of a type from other parts is to extract them into a separate 
> type, and even then, you can extend that new type anywhere in the file to 
> access the fragile parts. You're also likely to end up having members on the 
> outer type which simply call into equivalent members on the inner type. It 
> increases boilerplate and reduces protection.
> 
> Despite having used scoped `private` in the past, if the choice were between 
> keeping it and giving it `fileprivate` semantics, I would still support the 
> latter; I think the simplification would be worth the loss of tight 
> encapsulation. But this proposal offers *neither* simplification *nor* tight 
> encapsulation, so I'm opposed to it.
> 
> -- 
> 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] [Accepted] SE-0160: Limiting @objc inference

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md


The re-review of SE-0160 ran from March 31...April 2.  The proposal is 
accepted.  The feedback on the second round of review was very light and 
uniformly positive.

The proposal has been implemented in https://github.com/apple/swift/pull/8379.  
Early experience migrating a nontrivial Cocoa app (~200kloc, roughly half Swift 
and half Objective-C) resulted in a 5.7% decrease in code size (Release build) 
and required only 40 new @objc annotations, 37 of which were indicated by the 
new compiler warnings, 2 of which manifested as post-migration errors, and the 
last of which was found with the new (opt-in) runtime warnings.

Thank you to Doug Gregor for the proposal, and also the implementation of this 
improvement!

-Chris

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

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Robert Bennett via swift-evolution]

• What is your evaluation of the proposal?

-0.1

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

I don't think so. While Python's way of doing multiline strings may work for 
Python, I don't think it's an aesthetic fit for Swift, both because of the 
somewhat nebulous treatment of newlines and the magical-feeling indentation. 
Magic is a core component of Python, but has no place in Swift.

The alternative, continuation quotes, is my preferred solution to this problem. 
However I think it would be improved if lines began with a single quote or pipe 
or some other character, basically anything other than double quotes.

Advantages of continuation characters are that it is immediately clear how much 
leading whitespace a line actually has and that the string's value is 
insensitive to the indentation of the individual lines. The second point will 
be very useful when copying and pasting multiline strings, as the value of the 
string cannot change unless whitespace is explicitly inserted after the leading 
character. How many times have we copy-pasted code in Python, only to be stung 
by improper indentation of the pasted code? With a leading character on 
continuation lines, you can highlight and auto-indent — that's the only kind of 
magic that Swift should support.

If we want to make copying and pasting text from elsewhere (e.g., SQL queries) 
simple, then the compiler can provide a fix-it for multiline strings lacking 
continuation characters, offering to place the continuation character at the 
start of each line at the position determined by the start of the least 
indented offending line.


However, if we decide not to go with continuation quotes, then I largely agree 
with what Haravikk said here: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035188.html


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

I don't like stealing from Python because Swift's and Python's styles are very 
different. Swift should steer clear of Python's magic.

Aside from Python, no.

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

A quick read, and followed the discussion.


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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Michael LeHew via swift-evolution]

Yes, it is a hypothetical short head, not part of this proposal or any existing 
proposal currently. But it kind of fits.

-Michael 

> On Apr 6, 2017, at 6:21 PM, Ricardo Parada  wrote:
> 
> Hi,
> 
> I am trying to follow the emails.  Would that be same as KeyPath 
> ? Or what is that shorthand?
> 
> Thanks
> Ricardo
> 
> 
>> On Apr 6, 2017, at 8:32 PM, Michael J LeHew Jr via swift-evolution 
>>  wrote:
>> 
>> \Vector -> Int seems like a more appropriate spelling there no?   The : is 
>> usually for is-a/conforms-to relationships, no?
>> 
>> And I agree that such a thing could be considered later and would make the 
>> world a better place.
>> 
>> -Michael
>> 
 On Apr 6, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution 
  wrote:
 
 for key in [\Vector.x, \.y, \.z, \.w] {
a[key] += b[key]
 }
>>> 
>>> Sorry to derail slightly, but I'd love to see a key path type 
>>> shorthand—perhaps something like:
>>> 
>>> for key: \Vector: Int in [\.x, \.y, \.z, \.w] {
>>> …
>>> }
>>> 
>>> It's probably something we should defer until we know more about how 
>>> frequently people use key paths, though.
>>> 
>>> -- 
>>> 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-0169: Improve Interaction Between private Declarations and Extensions

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.
> 
> Who is currently doing that?

Me.

Even though I think we were better off without scoped `private`, I *have* used 
it fruitfully on several occasions. These were typically in places where I 
wanted to restrict access to a small number of members which I could ensure 
would enforce certain invariants. An example I gave previously involved two 
arrays which contained matching elements; code should never insert or remove 
from one array without doing the same to the other. By making these arrays 
`private` and exposing `fileprivate` and `public` members derived from them, I 
could ensure that only a couple dozen lines could possibly contain such a bug 
without changing the external design of the type or introducing boilerplate.

This proposal does not offer the same utility. The only way to protect fragile 
parts of a type from other parts is to extract them into a separate type, and 
even then, you can extend that new type anywhere in the file to access the 
fragile parts. You're also likely to end up having members on the outer type 
which simply call into equivalent members on the inner type. It increases 
boilerplate and reduces protection.

Despite having used scoped `private` in the past, if the choice were between 
keeping it and giving it `fileprivate` semantics, I would still support the 
latter; I think the simplification would be worth the loss of tight 
encapsulation. But this proposal offers *neither* simplification *nor* tight 
encapsulation, so I'm opposed to it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

[Ricardo Parada via swift-evolution]

How important is it that the closure be allowed to throw when resolving 
collisions?  In my use cases merging dictionaries he resolving of the 
collisions is always relatively simple.  Shouldn’t they be as below maybe?

/// Creates a new dictionary using the key/value pairs in the given 
sequence,
/// using a combining closure to determine the value for any duplicate keys.
init(
merging keysAndValues: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element

/// Merges the key/value pairs in the given sequence into the dictionary,
/// using a combining closure to determine the value for any duplicate keys.
mutating func merge(
_ other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element
/// Returns a new dictionary created by merging the key/value pairs in the
/// given sequence into the dictionary, using a combining closure to 
determine
/// the value for any duplicate keys.
func merged(
with other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) -> [Key: Value] where S.Iterator.Element == Element



> On Apr 6, 2017, at 12:51 PM, Nate Cook via swift-evolution 
>  wrote:
> 
>> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution 
>>> > wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> (As a meta issue, I'm not sure I like the grab-bag review style; I'm finding 
>> this proposal a little bit difficult to navigate.)
>> 
>> Sequence-based initializer and merging initializer
>> 
>> Good idea, but I think these two are redundant with each other, and I don't 
>> think "merging" is an accurate way to describe what the second one does. 
>> (`merging` would suggest to me that it was combining several dictionaries or 
>> lists, not combining conflicting elements.) I'd suggest a single initializer 
>> along the lines of:
>> 
>>  init(_ keysAndValues: S, correctingConflictsBy 
>> resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate 
>> values \($0) and \($1)") }) rethrows
>>  where S.Iterator.Element == (key: Key, value: Value)
> 
> Thanks for all your feedback, Brent! One note on this item in particular—if 
> you specify a default argument for a throws/rethrows closure, you have to use 
> "try" at the call site even if the default closure argument doesn't throw. 
> Modules currently don't promise that default closure arguments don't throw, 
> and a default argument could change from non-throwing to throwing in a later 
> version of a library.
> 
> There's a bug tracking the issue here: https://bugs.swift.org/browse/SR-2979 
> 
>> Merging methods
>> 
>> Good idea, but I'm not a fan of the `mergingValues:` label. I would suggest 
>> the same `correctingConflictsBy resolveConflict:` label I suggested for the 
>> previous method—possibly including the default value. I also think 
>> `merge(_:correctingConflictsBy:)`'s first parameter should be labeled 
>> `with`, just as the `merged` variant is.
>> 
>> I wonder if we might also want a method that copies the Dictionary, but with 
>> a single key added/removed/changed:
>> 
>>  func withValue(_ value: Value?, forKey key: Key) -> [Key: Value]
>> 
>> Key-based subscript with default value
>> 
>> I like the functionality, but not way this proposal does it. I don't like 
>> having the default value be a labeled parameter to the subscript, because it 
>> isn't used to locate the value. However, I can't come up with a better 
>> syntax without adding language features. What I'd like to do is make it 
>> possible to assign through `??`:
>> 
>>  frequencies[c] ?? 0 += 1
>> 
>> But that would require either that we support `inout` functions, or that 
>> `??` become magic syntax instead of a standard library feature. The former 
>> is not coming in Swift 4 and the latter is less than ideal.
>> 
>> Still, if we would rather have that syntax and we think we'll soon have the 
>> language improvements needed to pull it off, I'd suggest rejecting this 
>> portion of the proposal.
>> 
>> Dictionary-specific map and filter
>> 
>> I am +114 on this. I say that because I have received 114 upvotes on my 
>> Stack Overflow answer explaining how to write a `Dictionary.map` method: 
>> >  
>> >
>> 
>> I agree with the decision not to pass keys to the closures in these methods; 
>> that keeps them simple and 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Brent Royal-Gordon via swift-evolution]

Proposal link:

> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md


> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
> 
> What is your evaluation of the proposal?
This proposal is actively harmful. It will push people into using patterns we 
discourage, like converting between types by using properties or methods on the 
source type instead of initializers on the destination type. It will cause 
people to distort their designs, moving implementations into different types 
solely to gain access to `private` members.

I don't like scoped `private` either, but at least it has its uses: It's an 
effective tool when a member has fragile, easily-broken invariants and you want 
to ensure only carefully-audited code can use it. Type-and-file `private` is 
not fit for this purpose: Even if you segregate the fragile parts into a 
separate type, you can just extend that separate type anywhere else in the file 
and start messing with it. Frankly, I don't think type-and-file `private` is 
fit for *any* purpose.

At the same time, type-and-file `private` does not simplify our access modifier 
scheme, forces people to re-learn what `private` does *again*, and silently 
removes the protection that people currently rely on scoped `private` to 
provide without so much as a whimper from the compiler.

Keeping scoped `private` offers the following virtues:

* Your code doesn't change meaning or protection
* You don't have to re-learn what `private` means
* You can tightly protect fragile parts of a type, completely limiting 
visibility to one small region of the code

Making `private` and `fileprivate` aliases for one another offers the following 
virtues:

* You will never have to use the ugly `fileprivate` keyword
* Teaching and explaining access control is simpler
* You never have to put any piece of code in any particular type

Giving `private` type-and-file semantics offers the following virtues:

* You (hopefully) will have to use the ugly `fileprivate` keyword a little less 
often

That's it. That's *absurdly* far from being worth it.

This proposal is the worst of both worlds: weaker encapsulation without 
simplification, bad incentives without good guarantees, complexity without 
benefit, change without improvement. It should be rejected.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Access control is a mess, but this proposal does not address the things that 
make it a mess.

> Does this proposal fit well with the feel and direction of Swift?
No. This is a direction we have specifically and repeatedly chosen not to go in 
for many very good reasons. Those reasons still hold.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Swift 2's design was simple and elegant. Swift 3's was irritating but sometimes 
useful. This proposal keeps the irritation while discarding the usefulness.

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

Like all of us, I have spent *way* too much time arguing about access control 
in the last few months.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Rick Mann via swift-evolution]

I tend to dislike the backslash as well, but can't suggest a good alternative.

Does any of this allow for operations within the key path? e.g. 
Department.employees.@sum.salary?

Also, in this example:

let firstFriendsNameKeyPath = \Person.friends[0].name
let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"

Can't we do without the keyPath: argument name? The compiler knows it's a 
keypath, it would be nicer to write

let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"

> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be viewed 
> at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> 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/0161-key-paths.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


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charles Srstka via swift-evolution]

> On Apr 6, 2017, at 7:48 PM, Xiaodi Wu  wrote:
> 
> On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka  > wrote:
>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.
> 
> Who is currently doing that?
> 
> Presumably, proponents of SE-0025. That is, after all, an explicit part of 
> that design, reviewed and approved by the Swift community and core team.

I’m more interested in practicality than appeals to authority. If no one is 
actually using extensions in this way, then we don’t need it.

Charles

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

Hi,

I am trying to follow the emails.  Would that be same as KeyPath ? 
Or what is that shorthand?

Thanks
Ricardo


> On Apr 6, 2017, at 8:32 PM, Michael J LeHew Jr via swift-evolution 
>  wrote:
> 
> \Vector -> Int seems like a more appropriate spelling there no?   The : is 
> usually for is-a/conforms-to relationships, no?
> 
> And I agree that such a thing could be considered later and would make the 
> world a better place.
> 
> -Michael
> 
>> On Apr 6, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
>>> for key in [\Vector.x, \.y, \.z, \.w] {
>>> a[key] += b[key]
>>> }
>> 
>> Sorry to derail slightly, but I'd love to see a key path type 
>> shorthand—perhaps something like:
>> 
>>  for key: \Vector: Int in [\.x, \.y, \.z, \.w] {
>>  …
>>  }
>> 
>> It's probably something we should defer until we know more about how 
>> frequently people use key paths, though.
>> 
>> -- 
>> 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-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> Presumably, proponents of SE-0025. That is, after all, an explicit part of 
> that design, reviewed and approved by the Swift community and core team.

I'd be curious how many people actually are doing this though. My understanding 
is this practice is not that common overall.

Ultimately though, yes with any change like this there will be compromises. I 
personally believe the loss of this situation you're describing is far less 
than what there is to gain from this proposal.

> On Apr 6, 2017, at 5:48 PM, Xiaodi Wu  wrote:
> 
> On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka  
> wrote:
>>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> `private` works for extensions exactly how the authors of SE-0025 intended 
>>> it to do. Your comments do not address what would happen for those people 
>>> who are making use of this functionality currently to isolate methods to 
>>> the extension only.
>> 
>> Who is currently doing that?
> 
> Presumably, proponents of SE-0025. That is, after all, an explicit part of 
> that design, reviewed and approved by the Swift community and core team.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Thu, Apr 6, 2017 at 7:43 PM, Riley Testut  wrote:

> While valid, my understanding is that the use of extensions that *should *have
> access to private members is more common than the use of extensions to
> explicitly prevent access.
>
> More importantly though, using extensions to prevent access to private
> members can be accomplished by declaring the extensions in another file.
> The reverse is not true; extensions that *should* have access to private
> members is impossible.
>
> tl;dr; using extensions as a means to disallow access to private members
> is (from what I understand) far less common, and if someone really wanted
> to do that, they could instead declare the extensions in another file.
>

Not if those extensions are to access fileprivate members of the type. This
is the same argument that was rejected for SE-0159.


On Apr 6, 2017, at 5:34 PM, Xiaodi Wu  wrote:
>
> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I cannot express how strongly I believe this *is *the direction Swift
>> should go, so a huge, gigantic,
>>
>> +1
>> from me.
>>
>> After thinking it over, I do not have any qualms with fileprivate itself.
>> I think that the functionality provided by fileprivate is valuable, and I
>> also agree it shouldn’t be the default.
>>
>> *However*
>>
>> This proposal would solve the problems introduced by Swift 3’s private,
>> which has resulted in me defaulting to fileprivate for almost all “private”
>> variables due to my heavy use of extensions.
>>
>> Beyond me, however, I can attest that when teaching others Swift, they
>> initially are confused why private doesn’t work for extensions. To them, it
>> does not feel intuitive, and it certainly doesn’t to me either.
>>
>
> `private` works for extensions exactly how the authors of SE-0025 intended
> it to do. Your comments do not address what would happen for those people
> who are making use of this functionality currently to isolate methods to
> the extension only.
>
>
>> One argument I saw throughout these discussions was that this encourages
>> people to put all their code in one file. To that I ask, how is this any
>> different than what we have now? Fileprivate doesn’t fix this either.
>>
>> Ultimately, this keeps things *almost exactly the same* as what we have
>> now, but addresses the concerns of many in the Swift community. If you
>> don’t want to use private with extensions, people can simply *not use
>> private variables in extensions.*
>>
>> I genuinely believe this will satisfy the majority who were upset by
>> fileprivate, and I do not think it will affect those who were in favor of
>> fileprivate. So yes, again +1, and let’s *please* be done with this
>> fileprivate/private debate after this.
>>
>> (Also, I personally don’t view this as a “temporary workaround” like some
>> others. I would be very happy if this was the private/fileprivate solution
>> forever).
>>
>> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> If you don't want to resolve the mistake of SE-0025 by proposing a really
>> solution but not a workaround, then just leave the things where they are
>> currently. Proposed "improvement" IMO is more confusing than helping.
>>
>> Sorry, I don't buy <<..most of those proposals are not in scope for
>> discussion in Swift 4 (or any later release), given the significant impact
>> on source compatibility>>, because SE-0169 is also a source breaking
>> change, and the problem of access modifiers is important enough to relax
>> the rule of source compatibility for it, *especially if this is the last
>> chance*.
>> Also, it seems like core team was ready to accept SE-0159(Fix Private
>> Access Levels) which also has impact on source compatibility(given it
>> suggested to remove scoped-private).
>> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we
>> need.
>>
>> So, -1 from me.
>>
>> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>>
>> Hello Swift community,
>>
>> The review of SE-0169 "Improve Interaction Between private Declarations
>> and
>> Extensions" begins now and runs through April 11, 2017. The proposal is
>> available here:
>>
>>https://github.com/apple/swift-evolution/blob/master/prop
>> osals/0169-improve-interaction-between-private-declarations-
>> and-extensions.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/0169-improve-interaction-between-private-declarati
>> 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka 
wrote:

> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> `private` works for extensions exactly how the authors of SE-0025 intended
> it to do. Your comments do not address what would happen for those people
> who are making use of this functionality currently to isolate methods to
> the extension only.
>
>
> Who is currently doing that?
>

Presumably, proponents of SE-0025. That is, after all, an explicit part of
that design, reviewed and approved by the Swift community and core team.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.

My previous email was in response to this sorry. Ugh, mailing lists.

> On Apr 6, 2017, at 5:43 PM, Riley Testut  wrote:
> 
> While valid, my understanding is that the use of extensions that should have 
> access to private members is more common than the use of extensions to 
> explicitly prevent access.
> 
> More importantly though, using extensions to prevent access to private 
> members can be accomplished by declaring the extensions in another file. The 
> reverse is not true; extensions that should have access to private members is 
> impossible. 
> 
> tl;dr; using extensions as a means to disallow access to private members is 
> (from what I understand) far less common, and if someone really wanted to do 
> that, they could instead declare the extensions in another file.
> 
>> On Apr 6, 2017, at 5:34 PM, Xiaodi Wu  wrote:
>> 
>>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution 
>>>  wrote:
>>> I cannot express how strongly I believe this is the direction Swift should 
>>> go, so a huge, gigantic,
>>> 
>>> +1
>>> from me.
>>> 
>>> After thinking it over, I do not have any qualms with fileprivate itself. I 
>>> think that the functionality provided by fileprivate is valuable, and I 
>>> also agree it shouldn’t be the default.
>>> 
>>> However
>>> 
>>> This proposal would solve the problems introduced by Swift 3’s private, 
>>> which has resulted in me defaulting to fileprivate for almost all “private” 
>>> variables due to my heavy use of extensions.
>>> 
>>> Beyond me, however, I can attest that when teaching others Swift, they 
>>> initially are confused why private doesn’t work for extensions. To them, it 
>>> does not feel intuitive, and it certainly doesn’t to me either.
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.
>>  
>>> One argument I saw throughout these discussions was that this encourages 
>>> people to put all their code in one file. To that I ask, how is this any 
>>> different than what we have now? Fileprivate doesn’t fix this either.
>>> 
>>> Ultimately, this keeps things almost exactly the same as what we have now, 
>>> but addresses the concerns of many in the Swift community. If you don’t 
>>> want to use private with extensions, people can simply not use private 
>>> variables in extensions.
>>> 
>>> I genuinely believe this will satisfy the majority who were upset by 
>>> fileprivate, and I do not think it will affect those who were in favor of 
>>> fileprivate. So yes, again +1, and let’s please be done with this 
>>> fileprivate/private debate after this.
>>> 
>>> (Also, I personally don’t view this as a “temporary workaround” like some 
>>> others. I would be very happy if this was the private/fileprivate solution 
>>> forever).
>>> 
 On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
  wrote:
 
 If you don't want to resolve the mistake of SE-0025 by proposing a really 
 solution but not a workaround, then just leave the things where they are 
 currently. Proposed "improvement" IMO is more confusing than helping.
 
 Sorry, I don't buy <<..most of those proposals are not in scope for 
 discussion in Swift 4 (or any later release), given the significant impact 
 on source compatibility>>, because SE-0169 is also a source breaking 
 change, and the problem of access modifiers is important enough to relax 
 the rule of source compatibility for it, *especially if this is the last 
 chance*.
 Also, it seems like core team was ready to accept SE-0159(Fix Private 
 Access Levels) which also has impact on source compatibility(given it 
 suggested to remove scoped-private).
 IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we 
 need.
 
 So, -1 from me.
 
> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations 
> and
> Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> 
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
> 
>

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

While valid, my understanding is that the use of extensions that should have 
access to private members is more common than the use of extensions to 
explicitly prevent access.

More importantly though, using extensions to prevent access to private members 
can be accomplished by declaring the extensions in another file. The reverse is 
not true; extensions that should have access to private members is impossible. 

tl;dr; using extensions as a means to disallow access to private members is 
(from what I understand) far less common, and if someone really wanted to do 
that, they could instead declare the extensions in another file.

> On Apr 6, 2017, at 5:34 PM, Xiaodi Wu  wrote:
> 
>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution 
>>  wrote:
>> I cannot express how strongly I believe this is the direction Swift should 
>> go, so a huge, gigantic,
>> 
>> +1
>> from me.
>> 
>> After thinking it over, I do not have any qualms with fileprivate itself. I 
>> think that the functionality provided by fileprivate is valuable, and I also 
>> agree it shouldn’t be the default.
>> 
>> However
>> 
>> This proposal would solve the problems introduced by Swift 3’s private, 
>> which has resulted in me defaulting to fileprivate for almost all “private” 
>> variables due to my heavy use of extensions.
>> 
>> Beyond me, however, I can attest that when teaching others Swift, they 
>> initially are confused why private doesn’t work for extensions. To them, it 
>> does not feel intuitive, and it certainly doesn’t to me either.
> 
> `private` works for extensions exactly how the authors of SE-0025 intended it 
> to do. Your comments do not address what would happen for those people who 
> are making use of this functionality currently to isolate methods to the 
> extension only.
>  
>> One argument I saw throughout these discussions was that this encourages 
>> people to put all their code in one file. To that I ask, how is this any 
>> different than what we have now? Fileprivate doesn’t fix this either.
>> 
>> Ultimately, this keeps things almost exactly the same as what we have now, 
>> but addresses the concerns of many in the Swift community. If you don’t want 
>> to use private with extensions, people can simply not use private variables 
>> in extensions.
>> 
>> I genuinely believe this will satisfy the majority who were upset by 
>> fileprivate, and I do not think it will affect those who were in favor of 
>> fileprivate. So yes, again +1, and let’s please be done with this 
>> fileprivate/private debate after this.
>> 
>> (Also, I personally don’t view this as a “temporary workaround” like some 
>> others. I would be very happy if this was the private/fileprivate solution 
>> forever).
>> 
>>> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> If you don't want to resolve the mistake of SE-0025 by proposing a really 
>>> solution but not a workaround, then just leave the things where they are 
>>> currently. Proposed "improvement" IMO is more confusing than helping.
>>> 
>>> Sorry, I don't buy <<..most of those proposals are not in scope for 
>>> discussion in Swift 4 (or any later release), given the significant impact 
>>> on source compatibility>>, because SE-0169 is also a source breaking 
>>> change, and the problem of access modifiers is important enough to relax 
>>> the rule of source compatibility for it, *especially if this is the last 
>>> chance*.
>>> Also, it seems like core team was ready to accept SE-0159(Fix Private 
>>> Access Levels) which also has impact on source compatibility(given it 
>>> suggested to remove scoped-private).
>>> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we 
>>> need.
>>> 
>>> So, -1 from me.
>>> 
 On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
 Hello Swift community,
 
 The review of SE-0169 "Improve Interaction Between private Declarations and
 Extensions" begins now and runs through April 11, 2017. The proposal is
 available here:
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.md
 
Reply text
 
Other replies
 
 
  
 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charles Srstka via swift-evolution]

> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> `private` works for extensions exactly how the authors of SE-0025 intended it 
> to do. Your comments do not address what would happen for those people who 
> are making use of this functionality currently to isolate methods to the 
> extension only.

Who is currently doing that?

Charles

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Charles Srstka via swift-evolution]

+1 from me. This will solve the great majority of cases where “fileprivate” is 
currently needed, and will facilitate the common use case of splitting a type’s 
implementation into multiple extensions.

My only wish is that it applied to extensions in the same *module*, rather than 
the same *file*, so that we could use it to break up those obnoxious 3,000-line 
files that can result from having to squish everything into a single file. 
Compared to the status quo, however, this is an improvement.

Charles

> On Apr 6, 2017, at 6:10 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution <
swift-evolution@swift.org> wrote:

> I cannot express how strongly I believe this *is *the direction Swift
> should go, so a huge, gigantic,
>
> +1
> from me.
>
> After thinking it over, I do not have any qualms with fileprivate itself.
> I think that the functionality provided by fileprivate is valuable, and I
> also agree it shouldn’t be the default.
>
> *However*
>
> This proposal would solve the problems introduced by Swift 3’s private,
> which has resulted in me defaulting to fileprivate for almost all “private”
> variables due to my heavy use of extensions.
>
> Beyond me, however, I can attest that when teaching others Swift, they
> initially are confused why private doesn’t work for extensions. To them, it
> does not feel intuitive, and it certainly doesn’t to me either.
>

`private` works for extensions exactly how the authors of SE-0025 intended
it to do. Your comments do not address what would happen for those people
who are making use of this functionality currently to isolate methods to
the extension only.


> One argument I saw throughout these discussions was that this encourages
> people to put all their code in one file. To that I ask, how is this any
> different than what we have now? Fileprivate doesn’t fix this either.
>
> Ultimately, this keeps things *almost exactly the same* as what we have
> now, but addresses the concerns of many in the Swift community. If you
> don’t want to use private with extensions, people can simply *not use
> private variables in extensions.*
>
> I genuinely believe this will satisfy the majority who were upset by
> fileprivate, and I do not think it will affect those who were in favor of
> fileprivate. So yes, again +1, and let’s *please* be done with this
> fileprivate/private debate after this.
>
> (Also, I personally don’t view this as a “temporary workaround” like some
> others. I would be very happy if this was the private/fileprivate solution
> forever).
>
> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If you don't want to resolve the mistake of SE-0025 by proposing a really
> solution but not a workaround, then just leave the things where they are
> currently. Proposed "improvement" IMO is more confusing than helping.
>
> Sorry, I don't buy <<..most of those proposals are not in scope for
> discussion in Swift 4 (or any later release), given the significant impact
> on source compatibility>>, because SE-0169 is also a source breaking
> change, and the problem of access modifiers is important enough to relax
> the rule of source compatibility for it, *especially if this is the last
> chance*.
> Also, it seems like core team was ready to accept SE-0159(Fix Private
> Access Levels) which also has impact on source compatibility(given it
> suggested to remove scoped-private).
> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we
> need.
>
> So, -1 from me.
>
> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>
> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations and
> Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>https://github.com/apple/swift-evolution/blob/master/
> proposals/0169-improve-interaction-between-private-
> declarations-and-extensions.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/0169-improve-interaction-between-private-
> declarations-and-extensions.md
>
>Reply text
>
>Other replies
>
>
>   master/process.md#what-goes-into-a-review-1>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
>
> 

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

[Ben Cohen via swift-evolution]

> On Apr 5, 2017, at 10:32 PM, Félix Cloutier  wrote:
> 
> During the proposal phase, we asked how this would handle fixed-length 
> strings with an optional NUL terminator. For instance, in a C `struct Foo { 
> char name[8]; };`, `name` stops at the first \0, or at the eighth byte, 
> whichever comes first. IIRC, Ben said that it would be handled, but I'd like 
> to have it clarified.
> 
> Is it correct to assume that a UnicodeEncoding is expected to return 
> UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping 
> before the end of the buffer if necessary)? Is it also correct to assume that 
> if you need this functionality, you'll be looking at code like this?
> 
> var result = ""
> UnicodeEncoding.parseForward(bufferPointer) { result += $0 }
> 


Hi Félix,

Having talked about it among the team, it feels like we should add an 
initializer from a Collection of code units to this proposal.  Therefore given 
a pointer p to some utf8 and a length n, you would write:

let b = UnsafeBuffer(start: p, count: n)
// naming opinions on the argument labels welcomed, this is probably what I’d 
go for...
let s = String(b, fromEncoding: UTF8.self)

Similar to the C string inits, this would only be a repairing initializer.

Your request goes a little bit further though. For that, I would say that it 
probably doesn’t deserve a special dedicated initializer. You could instead 
search for the nil using index(of:):

let i = b.index(of: 0)
let s = String(b[..> Le 5 avr. 2017 à 11:39, John McCall via swift-evolution 
>> > a écrit :
>> 
>> Hello, Swift community!
>> 
>> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
>> Transcoding" begins now and runs through next Tuesday, April 11th. The 
>> proposal is available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.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/0155-normalize-enum-case-representation.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,
>> 
>> John McCall
>> 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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Michael J LeHew Jr via swift-evolution]

\Vector -> Int seems like a more appropriate spelling there no?   The : is 
usually for is-a/conforms-to relationships, no?

And I agree that such a thing could be considered later and would make the 
world a better place.

-Michael

> On Apr 6, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> for key in [\Vector.x, \.y, \.z, \.w] {
>>  a[key] += b[key]
>> }
> 
> Sorry to derail slightly, but I'd love to see a key path type 
> shorthand—perhaps something like:
> 
>   for key: \Vector: Int in [\.x, \.y, \.z, \.w] {
>   …
>   }
> 
> It's probably something we should defer until we know more about how 
> frequently people use key paths, though.
> 
> -- 
> 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-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

I cannot express how strongly I believe this is the direction Swift should go, 
so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself. I 
think that the functionality provided by fileprivate is valuable, and I also 
agree it shouldn’t be the default.

However

This proposal would solve the problems introduced by Swift 3’s private, which 
has resulted in me defaulting to fileprivate for almost all “private” variables 
due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they 
initially are confused why private doesn’t work for extensions. To them, it 
does not feel intuitive, and it certainly doesn’t to me either.

One argument I saw throughout these discussions was that this encourages people 
to put all their code in one file. To that I ask, how is this any different 
than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things almost exactly the same as what we have now, but 
addresses the concerns of many in the Swift community. If you don’t want to use 
private with extensions, people can simply not use private variables in 
extensions.

I genuinely believe this will satisfy the majority who were upset by 
fileprivate, and I do not think it will affect those who were in favor of 
fileprivate. So yes, again +1, and let’s please be done with this 
fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some 
others. I would be very happy if this was the private/fileprivate solution 
forever).

> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> If you don't want to resolve the mistake of SE-0025 by proposing a really 
> solution but not a workaround, then just leave the things where they are 
> currently. Proposed "improvement" IMO is more confusing than helping.
> 
> Sorry, I don't buy <<..most of those proposals are not in scope for 
> discussion in Swift 4 (or any later release), given the significant impact on 
> source compatibility>>, because SE-0169 is also a source breaking change, and 
> the problem of access modifiers is important enough to relax the rule of 
> source compatibility for it, *especially if this is the last chance*.
> Also, it seems like core team was ready to accept SE-0159(Fix Private Access 
> Levels) which also has impact on source compatibility(given it suggested to 
> remove scoped-private).
> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.
> 
> So, -1 from me.
> 
> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and
>> Extensions" begins now and runs through April 11, 2017. The proposal is
>> available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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
>> 
> 

Re: [swift-evolution] [Pitch] Rename fileprivate to shared

[Xiaodi Wu via swift-evolution]

On Thu, Apr 6, 2017 at 3:20 PM, James Froggatt via swift-evolution <
swift-evolution@swift.org> wrote:

> That's a shame if true, but my interpretation was that the rejection
> specifically cited the double-rename of fileprivate to private, and private
> to scoped, a major change which renames two access modifier, and reuses a
> spelling, making a staged migration impossible.
>

That's my understanding as well. The core team's promise at the end of
SE-0025 was that they would entertain future suggestions for `fileprivate`
should a superior spelling come about.

Since this suggestion is less impactful - affecting only one keyword, using
> a spelling with no prior meaning, and can be done as a staged transition
> (we can keep fileprivate around in Swift 4 while allowing shared and adding
> a warning to fileprivate), I hoped the core team might be willing to
> consider it.
>
> I think a lot of people would be pleased to be able to use a better
> spelling than fileprivate, even if it is never completely removed. This
> proposal would allow that.
>
> > On 6 Apr 2017, at 19:32, David Hart  wrote:
> >
> > Hi there,
> >
> > During the discussion that followed the rejection of SE-0159 the Core
> Team explained that they would not consider any rename to access control
> keywords, for the same reasons behind SE-0159's rejection: source
> compatibility. So I'm fairly sure this suggestion would go very far.
> >
> > David.
> >
> >> On 6 Apr 2017, at 16:30, James Froggatt via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> As the title says, I think renaming `fileprivate` to `shared` is the
> simplest way to solve the issues we have with spelling.
> >>
> >> My first line of reasoning is that it only affects one modifier,
> leaving private as it is. This minimises the amount of code affected,
> making it much more straightforward to migrate than the
> fileprivate-private-scoped switchup that has been suggested previously.
> >>
> >> My justification for `shared` as the new spelling is that it expresses
> *why* the developer would use the access level - to share implementation
> details with something, be it an extension or another type. It sounds
> natural and first-class, and fits well within the hierarchy.
> >>
> >> Private itself isn't too bad a default, and this change would leave it
> so, while making `shared` act as an informative identifier for where
> file-scope (or submodule-scope) sharing takes place. This would also hint
> at when the access level should be used from a design standpoint - more so
> than `fileprivate` or `file`.
> >> ___
> >> 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] Type-based ‘private’ access within a file

[Jordan Rose via swift-evolution]

> On Apr 6, 2017, at 17:04, Brent Royal-Gordon  wrote:
> 
>> On Apr 6, 2017, at 11:17 AM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we 
>> named the two levels "private" and "fileprivate", though I wish we hadn't; 
>> and now there is lots of existing code relying on that, and it would be mean 
>> and capricious to force people to change that code when they migrated to 
>> Swift 4. I don't like where we ended up but Swift does not exist in a vacuum.
> 
> 
> Could we revert `private` to its Swift 2 meaning, but keep `fileprivate` as a 
> compatibility alias with no plans to deprecate it until/unless we find that 
> the keyword has nearly disappeared from use? That'd be a wart, but in the 
> long run, I think it'd be less warty than living with an access control 
> design we're not happy with.

Sadly, no. The conclusion from SE-0159's review was that people are actively 
using scoped-private, even though you and I may not be.

Jordan

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

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Vladimir.S via swift-evolution]

If you don't want to resolve the mistake of SE-0025 by proposing a really 
solution but not a workaround, then just leave the things where they are 
currently. Proposed "improvement" IMO is more confusing than helping.


Sorry, I don't buy <<..most of those proposals are not in scope for 
discussion in Swift 4 (or any later release), given the significant impact 
on source compatibility>>, because SE-0169 is also a source breaking 
change, and the problem of access modifiers is important enough to relax 
the rule of source compatibility for it, *especially if this is the last 
chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private 
Access Levels) which also has impact on source compatibility(given it 
suggested to remove scoped-private).

IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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] Type-based ‘private’ access within a file

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 11:17 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we 
> named the two levels "private" and "fileprivate", though I wish we hadn't; 
> and now there is lots of existing code relying on that, and it would be mean 
> and capricious to force people to change that code when they migrated to 
> Swift 4. I don't like where we ended up but Swift does not exist in a vacuum.


Could we revert `private` to its Swift 2 meaning, but keep `fileprivate` as a 
compatibility alias with no plans to deprecate it until/unless we find that the 
keyword has nearly disappeared from use? That'd be a wart, but in the long run, 
I think it'd be less warty than living with an access control design we're not 
happy with.

-- 
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-0168: Multi-Line String Literals

[Xiaodi Wu via swift-evolution]

>
>
> • What is your evaluation of the proposal?
>

In terms of the overarching theme, I think it is delightful.

But I am very disappointed that this proposal did not first circulate as a
draft in the past few months prior to being sent out for review. I
understand that it is an abbreviated timeline for evolution, but there are
key elements missing from this proposal that need clarification before it
can properly be reviewed. Greg Parker covers some important questions, but
there are others too:

1. The proposal states that "any initial linefeed" is stripped:
- Is that one initial linefeed, or arbitrarily many initial linefeeds?
- Is that only LF, or also CR and/or CRLF?
- How about trailing LF, CR, and/or CRLF?
- If trailing LF/CR/CRLF is stripped, is it only one or arbitrarily
many?
- If arbitrarily many, would one have to escape trailing LF to avoid
such stripping (as in, `\n`)?
- If none are stripped, then how can one choose to specify the correct
indentation without the string obligatorily ending with an LF/CR/CRLF?

2. The proposal mentions breaking lines throughout and the term "linefeed"
only once. How are line endings treated?
- If they are normalized, is it to LF?
- If they are not normalized, how do you propose to have this interact with
git's recommended "core.autocrlf" setting, which will automatically change
your literal string if it's checked out on a different platform? (See:
https://help.github.com/articles/dealing-with-line-endings/)


• 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--well, it needs more detail to be a fully fleshed-out proposal.


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

Yes--and to answer the question about how this compares, we need more
detail.


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

I have thought about this off and on for quite some time.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Kevin Nattinger via swift-evolution]

> On Apr 6, 2017, at 6:10 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>  
> 
> ...
> 
> What is your evaluation of the proposal?
Strong +1. This would eliminate most of the need to unnecessarily expose 
private state to scopes where it doesn’t belong.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Very much so. I was surprised and disappointed to find out that private didn’t 
work this way already when 3 came out.

> Does this proposal fit well with the feel and direction of Swift?
Yes, it’s an important and necessary step.
Swift encourages splitting class implementations into a number of extensions 
for logical grouping, protocol conformance, etc. Currently, implementing 
classes this way often requires bumping private members to fileprivate, thereby 
dangerously exposing them to any other classes in the file.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Most languages don’t have this problem because the primary implementation isn’t 
normally broken into pieces in the same way.  I’d argue that the set of 
declaration + extensions that make up the primary body of the class are 
together equivalent to a single-body declaration in other languages, and 
therefore privates should be available to all pieces thereof.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed the several discussions about file/private access over the last year 
or two, and contributed to the current one.

> 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-0169: Improve Interaction Between private Declarations and Extensions

[Xiaodi Wu via swift-evolution]

For the reasons I outlined previously, a very strong -1 as well.

I thought it was worthwhile to consider if the Swift 2 design was superior
to the Swift 3 design, but I feel very strongly that there should not be a
Swift 4 "private" that's different from both Swift 3 and 2.
On Thu, Apr 6, 2017 at 18:25 Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Strong -1. This is a source breaking change, but Swift 4 stage 2 is
> already over.
>
> Slava
>
> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
>
> Hello Swift community,
>
> The review of SE-0169 "Improve Interaction Between private Declarations
> and Extensions" begins now and runs through April 11, 2017. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Slava Pestov via swift-evolution]

Strong -1. This is a source breaking change, but Swift 4 stage 2 is already 
over.

Slava

> On Apr 6, 2017, at 4:10 PM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0169 "Improve Interaction Between private Declarations and 
> Extensions" begins now and runs through April 11, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> for key in [\Vector.x, \.y, \.z, \.w] {
>   a[key] += b[key]
> }

Sorry to derail slightly, but I'd love to see a key path type shorthand—perhaps 
something like:

for key: \Vector: Int in [\.x, \.y, \.z, \.w] {
…
}

It's probably something we should defer until we know more about how frequently 
people use key paths, though.

-- 
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-0168: Multi-Line String Literals

[Jarod Long via swift-evolution]

> • What is your evaluation of the proposal?

I like the feature a lot, but I'm not so sure about the described 
indentation-stripping behavior. I don't think that putting the closing """ at 
the same indentation level as the string's contents is very intuitive. It feels 
a bit like writing this:

if someCondition {
    print("message")
    }

In general, the closing delimiter in a multiline context (for lack of a better 
general term) is indented to the same level as the line that contains the 
opening delimiter, so I think that unless developers are explicitly taught 
otherwise, they would likely default to that style for multiline strings, 
resulting in confusion about why there's an extra level of indentation in the 
interpreted multiline string.

I think what would be more intuitive and stylistically flexible would be to 
strip the largest amount leading whitespace that is common to each line. In 
other words, whichever line(s) that have the least amount of leading whitespace 
would determine the amount of indentation that gets stripped.

Apologies if this approach has been discussed before -- I missed most of the 
discussion that led to the proposal. Any thoughts on this?

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

Yes -- this would be a very useful feature in some situations.

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

I think so.

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

I haven't used this feature enough in other languages to comment here.

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

I read the proposal thoroughly.

Jarod

On Apr 6, 2017, 12:35 -0700, Joe Groff via swift-evolution 
, wrote:
> Hello Swift community,
>
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
>
> > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.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/0167-swift-encoders.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,
>
> -Joe
> 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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and 
Extensions" begins now and runs through April 11, 2017. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

[David Waite via swift-evolution]

> On Apr 5, 2017, at 12:39 PM, John McCall via swift-evolution 
>  wrote:
> 
> Hello, Swift community!
> 
> The review of "SE-163: String Revision: Collection Conformance, C Interop, 
> Transcoding" begins now and runs through next Tuesday, April 11th. The 
> proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md
>  
> 
>   • What is your evaluation of the proposal?
+1, looks great

>   • 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?
yes to both

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
I’ve yet to use a language with Swift’s unicode capabilities, but I might 
compare to Ruby 1.9+ strings, which support all encodings with one type. In 
comparison, I greatly prefer the “forcing” of the unicode and extended grapheme 
clusters mental model, rather than presenting a developer with sets of both 
array-of-characters and array-of-bytes semantics at once

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
Quick reading of proposal as well as reading of the String manifesto before.

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

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Víctor Pimentel Rodríguez via swift-evolution]

> On Thu, Apr 6, 2017 at 9:35 PM Joe Groff via swift-evolution 
>  wrote:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
> 
>   • What is your evaluation of the proposal?

+1

The first questions that pop into mind are "how do I write the character 
sequence """? And the literal \(something)?".

But if you think twice, those sequences would need to be escaped just like now 
with the existing simple string literals. So in the end if you know how to 
escape in a one-line literal, you know how to escape in a multi-line literal.

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

Yes. Though I would use it not every day, sometimes I really need this syntax 
and I would have loved to have it. Also, from my own experience, this is even 
more important for server-side Swift apps.

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

Very favorably, I think it trumps any other option that I've known and used, 
even some template languages.

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

I've followed the discussion and read the (small) proposal.

--
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 4:39 PM, Joe Groff  wrote:
> 
>> 
>> On Apr 6, 2017, at 2:35 PM, Matthew Johnson  wrote:
>> 
>>> 
>>> On Apr 6, 2017, at 4:22 PM, Joe Groff  wrote:
>>> 
 
 On Apr 6, 2017, at 2:15 PM, Matthew Johnson  wrote:
 
 
> On Apr 6, 2017, at 1:11 PM, Joe Groff  wrote:
> 
> 
>> On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
>> 
>>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  
>>> wrote:
 On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
 
> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>  wrote:
>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>>  wrote:
>> 
>> The rationale for using the same syntax is that a KeyPath is an 
>> unapplied property/subscript access. Even the multi-segment part of 
>> it isn't necessarily dissimilar: I don't think it would be 
>> unreasonable to imagine that \Foo.someMethod.someOtherMethod could 
>> work*, that'd just be function composition after all.
>> 
>> KeyPath : Properties/Subscripts :: Functions with a self argument : 
>> Methods
>> 
>>  David
>> 
>> *not proposing this, haven't thought carefully about whether there 
>> are edge cases I'm missing here, but I think the analogy holds
> 
> I alluded to this kind of thing in the earlier threads.  It would be 
> very cool to see this explored in the future.
> 
> I really like the latest draft and am eagerly anticipating Smart 
> KeyPaths being implemented.  Thank you for listening to feedback from 
> the community!
> 
> One possible future direction I have been wondering about is whether 
> it might be interesting to expose an anonymous type for each distinct 
> key path which would have static members for getting (and setting if 
> mutable) the value.  The types would inherit from the most specific 
> matching key path type included in this proposal. This would allow us 
> pass key paths statically using the type system and therefore not 
> requiring any runtime overhead.  
> 
> I have experimented with this approach in some of my own code and it 
> looks like it would be a very promising approach aside from the 
> boilerplate required to write these types manually.  I have abandoned 
> this approach for now because of the boilerplate and because the 
> syntactic sugar of the key path shorthand in this proposal is too 
> attractive to pass up.  I would love to explore it again in the 
> future if key paths were to support this approach.
 
 Our generics system does not require generic code to be de-genericized 
 ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
 order to be run. The generic code for applying a value of an unknown 
 key-path type would look exactly like the non-generic code for 
 applying a dynamic key-path type.  To get a runtime benefit, the 
 compiler would have to de-genericize all the code between the function 
 that formed the concrete key path and the function that applied it.  
 If the compiler can do that, it can also specialize that code for a 
 known key path argument, the same way that it can specialize a 
 function for a known function argument.  So there's no point.
>>> 
>>> Thanks for the reply John.  There may not be any additional 
>>> optimization opportunities in terms of code generation when using the 
>>> key path but wouldn’t it save on storage and reference counting related 
>>> to key path value?
>> 
>> If you're specializing all the way down, any sort of boxing should be 
>> possible to eliminate as well.
>> 
>> If you mean in unspecialized code, well, I'm not entirely sure what 
>> representation Joe is using, but I would assume that the fast path — 
>> where a key path doesn't capture anything — does not require any 
>> allocation.  In that sense, there's a strong parallel with how we 
>> represent functions: yes, avoiding an extra allocation would be nice, 
>> but if you're willing to accept an occasional allocation in more complex 
>> cases, there are also a lot of benefits from being able to always give 
>> the type a concrete, fixed-size representation.
> 
> Yeah, I've set up the implementation so that literal key paths get 
> emitted as global objects that don't need allocation, and shouldn't need 
> refcounting once the runtime gains 

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Kevin Nattinger via swift-evolution]

> On Apr 6, 2017, at 2:35 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
> ...
>   • What is your evaluation of the proposal?

+1
We definitely need a multi-line string solution, and I’m a fan of the 
python-like “”” solution.  

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

Favorably.
This is Largely the same as python, with the addition of leading-space 
stripping, the lack of which is one of the biggest gripes I’ve had and seen 
with python’s “”” implementation.

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

Followed both the original discussion and the recent revival closely. 

> 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Joe
> 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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff via swift-evolution]

> On Apr 6, 2017, at 2:35 PM, Matthew Johnson  wrote:
> 
>> 
>> On Apr 6, 2017, at 4:22 PM, Joe Groff  wrote:
>> 
>>> 
>>> On Apr 6, 2017, at 2:15 PM, Matthew Johnson  wrote:
>>> 
>>> 
 On Apr 6, 2017, at 1:11 PM, Joe Groff  wrote:
 
 
> On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
> 
>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  
>> wrote:
>>> On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
>>> 
 On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
  wrote:
> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>  wrote:
> 
> The rationale for using the same syntax is that a KeyPath is an 
> unapplied property/subscript access. Even the multi-segment part of 
> it isn't necessarily dissimilar: I don't think it would be 
> unreasonable to imagine that \Foo.someMethod.someOtherMethod could 
> work*, that'd just be function composition after all.
> 
> KeyPath : Properties/Subscripts :: Functions with a self argument : 
> Methods
> 
>   David
> 
> *not proposing this, haven't thought carefully about whether there 
> are edge cases I'm missing here, but I think the analogy holds
 
 I alluded to this kind of thing in the earlier threads.  It would be 
 very cool to see this explored in the future.
 
 I really like the latest draft and am eagerly anticipating Smart 
 KeyPaths being implemented.  Thank you for listening to feedback from 
 the community!
 
 One possible future direction I have been wondering about is whether 
 it might be interesting to expose an anonymous type for each distinct 
 key path which would have static members for getting (and setting if 
 mutable) the value.  The types would inherit from the most specific 
 matching key path type included in this proposal.  This would allow us 
 pass key paths statically using the type system and therefore not 
 requiring any runtime overhead.  
 
 I have experimented with this approach in some of my own code and it 
 looks like it would be a very promising approach aside from the 
 boilerplate required to write these types manually.  I have abandoned 
 this approach for now because of the boilerplate and because the 
 syntactic sugar of the key path shorthand in this proposal is too 
 attractive to pass up.  I would love to explore it again in the future 
 if key paths were to support this approach.
>>> 
>>> Our generics system does not require generic code to be de-genericized 
>>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
>>> order to be run.  The generic code for applying a value of an unknown 
>>> key-path type would look exactly like the non-generic code for applying 
>>> a dynamic key-path type.  To get a runtime benefit, the compiler would 
>>> have to de-genericize all the code between the function that formed the 
>>> concrete key path and the function that applied it.  If the compiler 
>>> can do that, it can also specialize that code for a known key path 
>>> argument, the same way that it can specialize a function for a known 
>>> function argument.  So there's no point.
>> 
>> Thanks for the reply John.  There may not be any additional optimization 
>> opportunities in terms of code generation when using the key path but 
>> wouldn’t it save on storage and reference counting related to key path 
>> value?
> 
> If you're specializing all the way down, any sort of boxing should be 
> possible to eliminate as well.
> 
> If you mean in unspecialized code, well, I'm not entirely sure what 
> representation Joe is using, but I would assume that the fast path — 
> where a key path doesn't capture anything — does not require any 
> allocation.  In that sense, there's a strong parallel with how we 
> represent functions: yes, avoiding an extra allocation would be nice, but 
> if you're willing to accept an occasional allocation in more complex 
> cases, there are also a lot of benefits from being able to always give 
> the type a concrete, fixed-size representation.
 
 Yeah, I've set up the implementation so that literal key paths get emitted 
 as global objects that don't need allocation, and shouldn't need 
 refcounting once the runtime gains support for inert objects. I also set 
 up the SIL representation for these in a way that we'll eventually be able 
 to do high-level optimization, so that 

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 4:22 PM, Joe Groff  wrote:
> 
>> 
>> On Apr 6, 2017, at 2:15 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 1:11 PM, Joe Groff  wrote:
>>> 
>>> 
 On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
 
> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  
> wrote:
>> On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
>> 
>>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
 On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
  wrote:
 
 The rationale for using the same syntax is that a KeyPath is an 
 unapplied property/subscript access. Even the multi-segment part of it 
 isn't necessarily dissimilar: I don't think it would be unreasonable 
 to imagine that \Foo.someMethod.someOtherMethod could work*, that'd 
 just be function composition after all.
 
 KeyPath : Properties/Subscripts :: Functions with a self argument : 
 Methods
 
David
 
 *not proposing this, haven't thought carefully about whether there are 
 edge cases I'm missing here, but I think the analogy holds
>>> 
>>> I alluded to this kind of thing in the earlier threads.  It would be 
>>> very cool to see this explored in the future.
>>> 
>>> I really like the latest draft and am eagerly anticipating Smart 
>>> KeyPaths being implemented.  Thank you for listening to feedback from 
>>> the community!
>>> 
>>> One possible future direction I have been wondering about is whether it 
>>> might be interesting to expose an anonymous type for each distinct key 
>>> path which would have static members for getting (and setting if 
>>> mutable) the value.  The types would inherit from the most specific 
>>> matching key path type included in this proposal.  This would allow us 
>>> pass key paths statically using the type system and therefore not 
>>> requiring any runtime overhead.  
>>> 
>>> I have experimented with this approach in some of my own code and it 
>>> looks like it would be a very promising approach aside from the 
>>> boilerplate required to write these types manually.  I have abandoned 
>>> this approach for now because of the boilerplate and because the 
>>> syntactic sugar of the key path shorthand in this proposal is too 
>>> attractive to pass up.  I would love to explore it again in the future 
>>> if key paths were to support this approach.
>> 
>> Our generics system does not require generic code to be de-genericized 
>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
>> order to be run.  The generic code for applying a value of an unknown 
>> key-path type would look exactly like the non-generic code for applying 
>> a dynamic key-path type.  To get a runtime benefit, the compiler would 
>> have to de-genericize all the code between the function that formed the 
>> concrete key path and the function that applied it.  If the compiler can 
>> do that, it can also specialize that code for a known key path argument, 
>> the same way that it can specialize a function for a known function 
>> argument.  So there's no point.
> 
> Thanks for the reply John.  There may not be any additional optimization 
> opportunities in terms of code generation when using the key path but 
> wouldn’t it save on storage and reference counting related to key path 
> value?
 
 If you're specializing all the way down, any sort of boxing should be 
 possible to eliminate as well.
 
 If you mean in unspecialized code, well, I'm not entirely sure what 
 representation Joe is using, but I would assume that the fast path — where 
 a key path doesn't capture anything — does not require any allocation.  In 
 that sense, there's a strong parallel with how we represent functions: 
 yes, avoiding an extra allocation would be nice, but if you're willing to 
 accept an occasional allocation in more complex cases, there are also a 
 lot of benefits from being able to always give the type a concrete, 
 fixed-size representation.
>>> 
>>> Yeah, I've set up the implementation so that literal key paths get emitted 
>>> as global objects that don't need allocation, and shouldn't need 
>>> refcounting once the runtime gains support for inert objects. I also set up 
>>> the SIL representation for these in a way that we'll eventually be able to 
>>> do high-level optimization, so that when we see a literal key path applied 
>>> to a concrete base, we can lower the key path application into direct 
>>> projections on the base value. Since everything is 

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff via swift-evolution]

> On Apr 6, 2017, at 2:15 PM, Matthew Johnson  wrote:
> 
> 
>> On Apr 6, 2017, at 1:11 PM, Joe Groff  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
>>> 
 On Apr 6, 2017, at 1:41 PM, Matthew Johnson  wrote:
> On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
> 
>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>>>  wrote:
>>> 
>>> The rationale for using the same syntax is that a KeyPath is an 
>>> unapplied property/subscript access. Even the multi-segment part of it 
>>> isn't necessarily dissimilar: I don't think it would be unreasonable to 
>>> imagine that \Foo.someMethod.someOtherMethod could work*, that'd just 
>>> be function composition after all.
>>> 
>>> KeyPath : Properties/Subscripts :: Functions with a self argument : 
>>> Methods
>>> 
>>> David
>>> 
>>> *not proposing this, haven't thought carefully about whether there are 
>>> edge cases I'm missing here, but I think the analogy holds
>> 
>> I alluded to this kind of thing in the earlier threads.  It would be 
>> very cool to see this explored in the future.
>> 
>> I really like the latest draft and am eagerly anticipating Smart 
>> KeyPaths being implemented.  Thank you for listening to feedback from 
>> the community!
>> 
>> One possible future direction I have been wondering about is whether it 
>> might be interesting to expose an anonymous type for each distinct key 
>> path which would have static members for getting (and setting if 
>> mutable) the value.  The types would inherit from the most specific 
>> matching key path type included in this proposal.  This would allow us 
>> pass key paths statically using the type system and therefore not 
>> requiring any runtime overhead.  
>> 
>> I have experimented with this approach in some of my own code and it 
>> looks like it would be a very promising approach aside from the 
>> boilerplate required to write these types manually.  I have abandoned 
>> this approach for now because of the boilerplate and because the 
>> syntactic sugar of the key path shorthand in this proposal is too 
>> attractive to pass up.  I would love to explore it again in the future 
>> if key paths were to support this approach.
> 
> Our generics system does not require generic code to be de-genericized 
> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
> order to be run.  The generic code for applying a value of an unknown 
> key-path type would look exactly like the non-generic code for applying a 
> dynamic key-path type.  To get a runtime benefit, the compiler would have 
> to de-genericize all the code between the function that formed the 
> concrete key path and the function that applied it.  If the compiler can 
> do that, it can also specialize that code for a known key path argument, 
> the same way that it can specialize a function for a known function 
> argument.  So there's no point.
 
 Thanks for the reply John.  There may not be any additional optimization 
 opportunities in terms of code generation when using the key path but 
 wouldn’t it save on storage and reference counting related to key path 
 value?
>>> 
>>> If you're specializing all the way down, any sort of boxing should be 
>>> possible to eliminate as well.
>>> 
>>> If you mean in unspecialized code, well, I'm not entirely sure what 
>>> representation Joe is using, but I would assume that the fast path — where 
>>> a key path doesn't capture anything — does not require any allocation.  In 
>>> that sense, there's a strong parallel with how we represent functions: yes, 
>>> avoiding an extra allocation would be nice, but if you're willing to accept 
>>> an occasional allocation in more complex cases, there are also a lot of 
>>> benefits from being able to always give the type a concrete, fixed-size 
>>> representation.
>> 
>> Yeah, I've set up the implementation so that literal key paths get emitted 
>> as global objects that don't need allocation, and shouldn't need refcounting 
>> once the runtime gains support for inert objects. I also set up the SIL 
>> representation for these in a way that we'll eventually be able to do 
>> high-level optimization, so that when we see a literal key path applied to a 
>> concrete base, we can lower the key path application into direct projections 
>> on the base value. Since everything is implemented using opaque classes now, 
>> there isn't much opportunity for specialization, but I think high-level 
>> optimizations are probably a better fit for the 

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

> On Apr 6, 2017, at 3:35 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
> 
>   • What is your evaluation of the proposal?

+1

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

As I had said before, it has to be simple and take care of most cases.  I 
wanted a continuation character but some people expressed being able to 
copy/paste right into the editor without much formatting.  And not having a 
continuation character will make this possible.

I think that using the closing triple quote to control how much indentation to 
remove from the previous lines is good enough.

String interpolation will be supported and I assume escaping of characters too. 
 So if someone wanted to embed a triple quote then they would have to escape 
the first one I'm guessing, ie. \""".  Although I am not that concerned because 
triple quotes is super rare in my use cases.

Being able to include quotes without having to escape them is also good as that 
was one of my main concerns.

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

I think it does.

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

Well java uses the concatenation.  This would be superior.  Other languages use 
"line 1" then on the next line you start with "line 2", and so on.  This would 
be superior as well because you can copy / paste right into the editor and be 
productive with minor formatting.  It will also allow quotes in the string.

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

Participated in the discussion and shared my ideas and goals for this feature.


> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Joe
> 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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 1:11 PM, Joe Groff  wrote:
> 
> 
>> On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
>> 
>>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  wrote:
 On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
 
> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>  wrote:
>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>>  wrote:
>> 
>> The rationale for using the same syntax is that a KeyPath is an 
>> unapplied property/subscript access. Even the multi-segment part of it 
>> isn't necessarily dissimilar: I don't think it would be unreasonable to 
>> imagine that \Foo.someMethod.someOtherMethod could work*, that'd just be 
>> function composition after all.
>> 
>> KeyPath : Properties/Subscripts :: Functions with a self argument : 
>> Methods
>> 
>>  David
>> 
>> *not proposing this, haven't thought carefully about whether there are 
>> edge cases I'm missing here, but I think the analogy holds
> 
> I alluded to this kind of thing in the earlier threads.  It would be very 
> cool to see this explored in the future.
> 
> I really like the latest draft and am eagerly anticipating Smart KeyPaths 
> being implemented.  Thank you for listening to feedback from the 
> community!
> 
> One possible future direction I have been wondering about is whether it 
> might be interesting to expose an anonymous type for each distinct key 
> path which would have static members for getting (and setting if mutable) 
> the value.  The types would inherit from the most specific matching key 
> path type included in this proposal.  This would allow us pass key paths 
> statically using the type system and therefore not requiring any runtime 
> overhead.  
> 
> I have experimented with this approach in some of my own code and it 
> looks like it would be a very promising approach aside from the 
> boilerplate required to write these types manually.  I have abandoned 
> this approach for now because of the boilerplate and because the 
> syntactic sugar of the key path shorthand in this proposal is too 
> attractive to pass up.  I would love to explore it again in the future if 
> key paths were to support this approach.
 
 Our generics system does not require generic code to be de-genericized 
 ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
 order to be run.  The generic code for applying a value of an unknown 
 key-path type would look exactly like the non-generic code for applying a 
 dynamic key-path type.  To get a runtime benefit, the compiler would have 
 to de-genericize all the code between the function that formed the 
 concrete key path and the function that applied it.  If the compiler can 
 do that, it can also specialize that code for a known key path argument, 
 the same way that it can specialize a function for a known function 
 argument.  So there's no point.
>>> 
>>> Thanks for the reply John.  There may not be any additional optimization 
>>> opportunities in terms of code generation when using the key path but 
>>> wouldn’t it save on storage and reference counting related to key path 
>>> value?
>> 
>> If you're specializing all the way down, any sort of boxing should be 
>> possible to eliminate as well.
>> 
>> If you mean in unspecialized code, well, I'm not entirely sure what 
>> representation Joe is using, but I would assume that the fast path — where a 
>> key path doesn't capture anything — does not require any allocation.  In 
>> that sense, there's a strong parallel with how we represent functions: yes, 
>> avoiding an extra allocation would be nice, but if you're willing to accept 
>> an occasional allocation in more complex cases, there are also a lot of 
>> benefits from being able to always give the type a concrete, fixed-size 
>> representation.
> 
> Yeah, I've set up the implementation so that literal key paths get emitted as 
> global objects that don't need allocation, and shouldn't need refcounting 
> once the runtime gains support for inert objects. I also set up the SIL 
> representation for these in a way that we'll eventually be able to do 
> high-level optimization, so that when we see a literal key path applied to a 
> concrete base, we can lower the key path application into direct projections 
> on the base value. Since everything is implemented using opaque classes now, 
> there isn't much opportunity for specialization, but I think high-level 
> optimizations are probably a better fit for the common cases.

If I understand this correctly the storage for key path values that begin as a 
literal would be a non-refcounted word after inert object support is included 
in the 

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 2:54 PM, John McCall  wrote:
> 
>> 
>> On Apr 6, 2017, at 3:05 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Apr 6, 2017, at 1:21 PM, John McCall >> > wrote:
>>> 
 On Apr 6, 2017, at 2:12 PM, Matthew Johnson > wrote:
> On Apr 6, 2017, at 1:06 PM, John McCall  > wrote:
> 
>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson > > wrote:
>>> On Apr 6, 2017, at 12:32 PM, John McCall >> > wrote:
>>> 
 On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
 > wrote:
> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
> > wrote:
> 
> The rationale for using the same syntax is that a KeyPath is an 
> unapplied property/subscript access. Even the multi-segment part of 
> it isn't necessarily dissimilar: I don't think it would be 
> unreasonable to imagine that \Foo.someMethod.someOtherMethod could 
> work*, that'd just be function composition after all.
> 
> KeyPath : Properties/Subscripts :: Functions with a self argument : 
> Methods
> 
>   David
> 
> *not proposing this, haven't thought carefully about whether there 
> are edge cases I'm missing here, but I think the analogy holds
 
 I alluded to this kind of thing in the earlier threads.  It would be 
 very cool to see this explored in the future.
 
 I really like the latest draft and am eagerly anticipating Smart 
 KeyPaths being implemented.  Thank you for listening to feedback from 
 the community!
 
 One possible future direction I have been wondering about is whether 
 it might be interesting to expose an anonymous type for each distinct 
 key path which would have static members for getting (and setting if 
 mutable) the value.  The types would inherit from the most specific 
 matching key path type included in this proposal.  This would allow us 
 pass key paths statically using the type system and therefore not 
 requiring any runtime overhead.  
 
 I have experimented with this approach in some of my own code and it 
 looks like it would be a very promising approach aside from the 
 boilerplate required to write these types manually.  I have abandoned 
 this approach for now because of the boilerplate and because the 
 syntactic sugar of the key path shorthand in this proposal is too 
 attractive to pass up.  I would love to explore it again in the future 
 if key paths were to support this approach.
>>> 
>>> Our generics system does not require generic code to be de-genericized 
>>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
>>> order to be run.  The generic code for applying a value of an unknown 
>>> key-path type would look exactly like the non-generic code for applying 
>>> a dynamic key-path type.  To get a runtime benefit, the compiler would 
>>> have to de-genericize all the code between the function that formed the 
>>> concrete key path and the function that applied it.  If the compiler 
>>> can do that, it can also specialize that code for a known key path 
>>> argument, the same way that it can specialize a function for a known 
>>> function argument.  So there's no point.
>> 
>> Thanks for the reply John.  There may not be any additional optimization 
>> opportunities in terms of code generation when using the key path but 
>> wouldn’t it save on storage and reference counting related to key path 
>> value?
> 
> If you're specializing all the way down, any sort of boxing should be 
> possible to eliminate as well.
> 
> If you mean in unspecialized code, well, I'm not entirely sure what 
> representation Joe is using, but I would assume that the fast path — 
> where a key path doesn't capture anything — does not require any 
> allocation.  In that sense, there's a strong parallel with how we 
> represent functions: yes, avoiding an extra allocation would be nice, but 
> if you're willing to accept an occasional allocation in more complex 
> cases, there are also a lot of benefits from being able to always give 
> the type a concrete, fixed-size representation.
 
 Key paths in this proposal are classes which require storage of the 
 pointer 

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

[Gelareh Taban via swift-evolution]

Hi Rien,

This is great, thanks for referencing your blogs/repo. I'll go through
them.
(An unfortunate issue I have found with security is that, we need it, we
expect it, but we don't want to worry about it :-)

The basic structure of what we are considering right now would to a large
extent follow that of
https://github.com/IBM-Swift/BlueSSLService/
which invokes SecureTransport on Apple and OpenSSL on Linux.

For more details of some of the discussions, just follow this thread.
https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20170320/000298.html

Would love to have your contributions here! :-D

gelareh






From:   Rien 
To: Gelareh Taban/Austin/IBM@IBMUS
Cc: swift-evolution@swift.org
Date:   04/06/2017 11:54 AM
Subject:Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library



Having just finished a client/server framework that builds on openSSL I
sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And
those leads me to believe that there is not much interest in secure
networking. The number of hits on those posts are quite low (anaemic even)
when compared to -for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that
the API will become complex so fast, that it will not be much easier to use
than openSSL/LibreSSL etc. But don’t let that stop you ;-)

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets


Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution
 wrote:
>
> Hi all,
>
> I’d like to pitch some of the ideas that have been discussed in the
server working group around security.
>
> To get more information on the server API group and its goals, see
https://swift.org/server-apis/. (TL;DR version is to come up with a set of
foundational APIs that work cross-platform, on all platforms supported by
Swift, including Linux.)
>
> For security, we have divided the scope into SSL/TLS support and crypto
support. Our first goal and the subject of this pitch is TLS. This current
pitch is the result of various discussions that have taken place over the
past several months over the server working group mailing list and several
projects by groups such as Vapor, IBM, Zewo, etc.
>
> Our plan is to start with the main ideas presented here and work on a
Swift library that we prototype and iterate on before finalizing on a
specific interface. Hopefully the ideas in this pitch are
non-controversial, aside from the naming of the method and protocols (which
is widely accepted as a `hard` problem).
>
> # Problem
>
> Since there is currently no standard Swift SSL/TLS library that is
compatible on both Apple and Linux, Swift projects use their TLS library of
choice (such as OpenSSL, LibreSSL, Security framework, etc). This results
in:
> - fragmentation of the space as well as incompatibility of project
dependencies if more than one security package is needed by different
modules (a project cannot have both OpenSSL and LibreSSL in its dependency
graph)
> - insecurity (using an unpatched or deprecated library such as OpenSSL on
macOS)
> - unmaintainablity (using non-standard or non-native libraries)
> - more complex code (using different APIs or code paths for each
platform).
>
> So we want to propose a standard set of protocols that define the
behavior of the TLS service and how the application and the server and
networking layers beneath it interact with the TLS service. What
complicates this pitch is that the Swift in server space is new and none of
the interfaces have yet been defined, so this is really a work in
iteration.
>
> # Design goals
>
> We came up with the following design goals for a solution:
>
> - Provide a consistent and unified Swift interface so that the developer
can write simple, cross-platform applications;
> - Don't implement new crypto functionality and instead use existing
functions in underlying libraries;
> - Plug-n-play architecture which allows the developer to decide on
underlying security library of choice, e.g., OpenSSL vs LibreSSL;
> - Library should be agnostic of the transport mechanism (e.g., socket,
etc), whilst allowing for both blocking and non-blocking connections;
> - Developers should be able to use the same TLS library for both client
and server applications.
>
>
> # Proposal
>
> The proposed solution basically defines a number of protocols for each
interface:
> - Transport management
> - TLS management
>
> A basic diagram that shows the relationship between the proposed
protocols is shown below:
>
> (See attached file: TLSServiceArchitecture.png)
>
> ![alt text](
https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png
 "Architecture of TLSService modules")
>
>
> The 

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Daniel Duan via swift-evolution]

>   • What is your evaluation of the proposal?
I support the initiative. But I have the question as Greg and Tony: how would 
one write “”” in side the literal?

>   • 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 like stealing from Python.

I particularly like the whitespace striping algorithm. In Python, multiline 
literal is often awkward because the literal gets mixed up with whitespaces 
from indentation, when programmer adjust for that, the body of the literal 
breaks the indentation and looks jarring.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
A quick read.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Vladimir.S via swift-evolution]

On 06.04.2017 22:35, Joe Groff via swift-evolution wrote:

Hello Swift community,

The review of SE-0168 "Multi-Line String Literals" begins now and runs
through April 12, 2017. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md



Is text on the same line of """ allowed?

Can opening and closing """ be on the same line?
I.e. :
print("""is text allowed here?
text
text
""");

print("""
text
text
and there?""");

print("""allowed?""");


What line-end characters will be actually added at the end of each line?
( '\r' ? '\n' ? "\r\n" ? other ? )
Sometimes it can be important what char(s) is a marker of the line end for 
the code that *receives* our multi-line string.


How to paste """ inside a multi-line string ?

How to paste these two symbols \( inside a multi-line string (i.e. just 
symbols, not beginning of string interpolation block) ?

Should single backslash be escaped ?




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/0167-swift-encoders.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,

-Joe
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] [Review] SE-0168: Multi-Line String Literals

[David Hart via swift-evolution]

> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution 
>> > wrote:
>> 
>>  • What is your evaluation of the proposal?
> 
> I'm a -1 for several reasons, mostly subjective but still. First thing is 
> that I'm generally not comfortable with encouraging the use of multi-line 
> strings at all. These are things that usually should be templated or 
> localised, and personally I don't see what's inconvenient about concatenating 
> on those occasions where you can't (or just don't want to); I'm actually of 
> the opinion that this is the kind of thing that should be awkward and 
> annoying, to encourage developers to think about what they're doing.

IMHO, there are plenty of uses for multi-line strings that are entire valid and 
acceptable. SQL queries is the example I encounter the most in my day-to-day 
work. And concatenating makes working with them very cumbersome.

> My second issue really is that, if the aim is simply to indent your 
> multi-line string more nicely, then is this actually something that the 
> language has to solve? I know we don't like to consider proposals purely from 
> the perspective of what an IDE may, or may not, do, but this seems like a 
> case where a good IDE could take:
> 
> let foo = "This is my
> multi-line
> text"
> 
> And display it visually to look like:
> 
> let foo = "This is my
>   multi-line
>   text"
> 
> This is basically what Xcode does for line-wrapped text right now. While it 
> would mean people using more basic editors would still see the original, it's 
> not really like that's a major problem.
> 
> Another alternative might be a compiler directive that is more explicit about 
> what you want to do, for example:
> 
> let foo = #trimleft("
>   This is my
>   multi-line
>   text
> ")
> 
> Here the directive would look at the text as a whole and see that all lines 
> are indented by at least one tab, and so strip one tab from each line. 
> There's probably a better name for the directive, but hopefully you hopefully 
> get the idea, as this is much more explicit about what you want to do.
> 
> Also, one thing that really stands out with the proposal is how unwise the 
> example is; the fact that the assertion relies on leading whitespace being 
> stripped from the multi-line HTML makes it clear why things like this may not 
> be a good idea, as if the code is edited to produce indented HTML then the 
> assertion will fail, even if the HTML is still correct. The continuation 
> quotes example makes this more obvious as it actually include some of the 
> whitespace, so which is correct?
> 
> I don't want to seem too negative, I just think that whitespace stripping 
> multi-line strings are a weird thing to want in a language. If an easier 
> multi-line syntax has to be added then my preference would be for the 
> alternative continuation quotes personally, as it's more explicit about what 
> is included, though I still say there's nothing wrong with just doing the 
> concatenation and newline characters IMO, as it's fully supported today and 
> not really that much more burdensome to do (and it being a bit more difficult 
> may be a good thing, as I say).
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Not really. We can already do multi-line by either putting newlines inside 
> quotes and leaving out indentation, or by concatenating lines terminated with 
> the new-line character. IMO these two existing options are enough as it is.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> I'm not sure; in terms of simplicity I think that adding new syntax for 
> multi-line strings is an unnecessary added complexity and something else to 
> learn, and doesn't enable anything we can't already do fairly easily.
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> All of the proposed syntaxes are present in various languages, I've used many 
> of them, and I know from my own bad habits that 99% of the time I shouldn't 
> have 
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Followed the discussion and re-read the 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] [Review] SE-0168: Multi-Line String Literals

[Haravikk via swift-evolution]

> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution 
>  wrote:
> 
>   • What is your evaluation of the proposal?

I'm a -1 for several reasons, mostly subjective but still. First thing is that 
I'm generally not comfortable with encouraging the use of multi-line strings at 
all. These are things that usually should be templated or localised, and 
personally I don't see what's inconvenient about concatenating on those 
occasions where you can't (or just don't want to); I'm actually of the opinion 
that this is the kind of thing that should be awkward and annoying, to 
encourage developers to think about what they're doing.

My second issue really is that, if the aim is simply to indent your multi-line 
string more nicely, then is this actually something that the language has to 
solve? I know we don't like to consider proposals purely from the perspective 
of what an IDE may, or may not, do, but this seems like a case where a good IDE 
could take:

let foo = "This is my
multi-line
text"

And display it visually to look like:

let foo = "This is my
multi-line
text"

This is basically what Xcode does for line-wrapped text right now. While it 
would mean people using more basic editors would still see the original, it's 
not really like that's a major problem.

Another alternative might be a compiler directive that is more explicit about 
what you want to do, for example:

let foo = #trimleft("
This is my
multi-line
text
")

Here the directive would look at the text as a whole and see that all lines are 
indented by at least one tab, and so strip one tab from each line. There's 
probably a better name for the directive, but hopefully you hopefully get the 
idea, as this is much more explicit about what you want to do.

Also, one thing that really stands out with the proposal is how unwise the 
example is; the fact that the assertion relies on leading whitespace being 
stripped from the multi-line HTML makes it clear why things like this may not 
be a good idea, as if the code is edited to produce indented HTML then the 
assertion will fail, even if the HTML is still correct. The continuation quotes 
example makes this more obvious as it actually include some of the whitespace, 
so which is correct?

I don't want to seem too negative, I just think that whitespace stripping 
multi-line strings are a weird thing to want in a language. If an easier 
multi-line syntax has to be added then my preference would be for the 
alternative continuation quotes personally, as it's more explicit about what is 
included, though I still say there's nothing wrong with just doing the 
concatenation and newline characters IMO, as it's fully supported today and not 
really that much more burdensome to do (and it being a bit more difficult may 
be a good thing, as I say).

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

Not really. We can already do multi-line by either putting newlines inside 
quotes and leaving out indentation, or by concatenating lines terminated with 
the new-line character. IMO these two existing options are enough as it is.

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

I'm not sure; in terms of simplicity I think that adding new syntax for 
multi-line strings is an unnecessary added complexity and something else to 
learn, and doesn't enable anything we can't already do fairly easily.

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

All of the proposed syntaxes are present in various languages, I've used many 
of them, and I know from my own bad habits that 99% of the time I shouldn't 
have 

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

Followed the discussion and re-read the proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Rename fileprivate to shared

[James Froggatt via swift-evolution]

That's a shame if true, but my interpretation was that the rejection 
specifically cited the double-rename of fileprivate to private, and private to 
scoped, a major change which renames two access modifier, and reuses a 
spelling, making a staged migration impossible.

Since this suggestion is less impactful - affecting only one keyword, using a 
spelling with no prior meaning, and can be done as a staged transition (we can 
keep fileprivate around in Swift 4 while allowing shared and adding a warning 
to fileprivate), I hoped the core team might be willing to consider it.

I think a lot of people would be pleased to be able to use a better spelling 
than fileprivate, even if it is never completely removed. This proposal would 
allow that.

> On 6 Apr 2017, at 19:32, David Hart  wrote:
> 
> Hi there,
> 
> During the discussion that followed the rejection of SE-0159 the Core Team 
> explained that they would not consider any rename to access control keywords, 
> for the same reasons behind SE-0159's rejection: source compatibility. So I'm 
> fairly sure this suggestion would go very far.
> 
> David.
> 
>> On 6 Apr 2017, at 16:30, James Froggatt via swift-evolution 
>>  wrote:
>> 
>> As the title says, I think renaming `fileprivate` to `shared` is the 
>> simplest way to solve the issues we have with spelling.
>> 
>> My first line of reasoning is that it only affects one modifier, leaving 
>> private as it is. This minimises the amount of code affected, making it much 
>> more straightforward to migrate than the fileprivate-private-scoped switchup 
>> that has been suggested previously.
>> 
>> My justification for `shared` as the new spelling is that it expresses *why* 
>> the developer would use the access level - to share implementation details 
>> with something, be it an extension or another type. It sounds natural and 
>> first-class, and fits well within the hierarchy.
>> 
>> Private itself isn't too bad a default, and this change would leave it so, 
>> while making `shared` act as an informative identifier for where file-scope 
>> (or submodule-scope) sharing takes place. This would also hint at when the 
>> access level should be used from a design standpoint - more so than 
>> `fileprivate` or `file`.
>> ___
>> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 1:15 PM, Michael J LeHew Jr  wrote:
> 
> 
>> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Apr 6, 2017, at 10:28 AM, Ricardo Parada >> > wrote:
>>> 
>>> Do you think in the future it might be possible to convert to strings?  
>>> 
>>> For example, I am imagining a CoreData-like framework on the server (where 
>>> there is no Objective-C), where I would like to get the type of the root 
>>> object and keys forming the path.  That way I can go to an object model, 
>>> get the corresponding entity, and traversed relationships, and destination 
>>> attribute.  All that information (table name, table joins for the 
>>> relationships traversed, column names, etc.) would then be used to 
>>> construct the SQL.
>> 
>> Key-paths could be extended to allow introspection of the components along 
>> the path, in which case you would be able to map between key paths into your 
>> specific data model and the tables/columns in your database. This is not the 
> 
> ... ?  You left us hanging there Doug! :)

Eh, sorry! Making key-paths Codable could definitely make sense in the future, 
as you note. But I don’t know that a “blessed String representation” makes 
sense for key-paths.

> 
> We do mention in the proposal that support for marshalling to external 
> representation (String, Codable should that be accepted, etc) would highly 
> desirable in the future, for IB / CoreData type scenarios and more.  It is 
> one of the principle reasons we decided not to allow key paths to compose 
> with transformations (functions and closures), as while that is very powerful 
> and interesting, once you go there you're not really a key path any more. 
> 
> It's not part of this initial proposal, but could easily be brought up as a 
> follow-on in the future. 

Right.

- Doug

> 
>> 
>>  - Doug
>> 
>>> 
>>> 
>>> 
 On Apr 6, 2017, at 12:37 PM, Douglas Gregor > wrote:
 
> 
> On Apr 6, 2017, at 9:31 AM, Sean Heber  > wrote:
> 
> 
>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>>> > wrote:
>>> 
>>> I agree, there's an analogy between strings and key paths, and in that 
>>> regards the single quote would make sense.  I would not complain.  
>> 
>> The only analogy between strings and key-paths is that the existing 
>> Cocoa APIs for key-paths use strings. That’s not an analogy to hang 
>> language syntax on, because it’s relevance will fade quickly. 
> 
> Why would it fade quickly? Do we expect the concept of keypaths to go 
> away over time? If so, why are we even designing a syntax for keypaths?
 
 The link between key-paths and strings will go away over time. The *only* 
 reason anyone associates strings with keypaths is because Cocoa’s current 
 key-paths are string-based. This proposal makes any string representation 
 of key-paths an implementation detail that could be used for 
 interoperability with Cocoa’s current system. There is no reason for a 
 type-unsafe string representation to ever be in the user model.
 
 
>> The core team discussed single quotes, and decided that we want to save 
>> them for something in the string/character realm.
> 
> Are they to be saved for something specific or is this just because a lot 
> of languages use single quotes for character literals? Why is this 
> association any more sacred than an association with Cocoa string 
> keypaths?
 
 
 Lots of languages use single quotes for character literals; we may want to 
 bring them back for it.
 
- Doug
>>> 
>> 
>> ___
>> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Michael J LeHew Jr via swift-evolution]

> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Apr 6, 2017, at 10:28 AM, Ricardo Parada > > wrote:
>> 
>> Do you think in the future it might be possible to convert to strings?  
>> 
>> For example, I am imagining a CoreData-like framework on the server (where 
>> there is no Objective-C), where I would like to get the type of the root 
>> object and keys forming the path.  That way I can go to an object model, get 
>> the corresponding entity, and traversed relationships, and destination 
>> attribute.  All that information (table name, table joins for the 
>> relationships traversed, column names, etc.) would then be used to construct 
>> the SQL.
> 
> Key-paths could be extended to allow introspection of the components along 
> the path, in which case you would be able to map between key paths into your 
> specific data model and the tables/columns in your database. This is not the 

... ?  You left us hanging there Doug! :)

We do mention in the proposal that support for marshalling to external 
representation (String, Codable should that be accepted, etc) would highly 
desirable in the future, for IB / CoreData type scenarios and more.  It is one 
of the principle reasons we decided not to allow key paths to compose with 
transformations (functions and closures), as while that is very powerful and 
interesting, once you go there you're not really a key path any more. 

It's not part of this initial proposal, but could easily be brought up as a 
follow-on in the future. 

-Michael


> 
>   - Doug
> 
>> 
>> 
>> 
>>> On Apr 6, 2017, at 12:37 PM, Douglas Gregor >> > wrote:
>>> 
 
 On Apr 6, 2017, at 9:31 AM, Sean Heber > wrote:
 
 
> On Apr 6, 2017, at 11:19 AM, Douglas Gregor  > wrote:
> 
>> 
>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>> > wrote:
>> 
>> I agree, there's an analogy between strings and key paths, and in that 
>> regards the single quote would make sense.  I would not complain.  
> 
> The only analogy between strings and key-paths is that the existing Cocoa 
> APIs for key-paths use strings. That’s not an analogy to hang language 
> syntax on, because it’s relevance will fade quickly. 
 
 Why would it fade quickly? Do we expect the concept of keypaths to go away 
 over time? If so, why are we even designing a syntax for keypaths?
>>> 
>>> The link between key-paths and strings will go away over time. The *only* 
>>> reason anyone associates strings with keypaths is because Cocoa’s current 
>>> key-paths are string-based. This proposal makes any string representation 
>>> of key-paths an implementation detail that could be used for 
>>> interoperability with Cocoa’s current system. There is no reason for a 
>>> type-unsafe string representation to ever be in the user model.
>>> 
>>> 
> The core team discussed single quotes, and decided that we want to save 
> them for something in the string/character realm.
 
 Are they to be saved for something specific or is this just because a lot 
 of languages use single quotes for character literals? Why is this 
 association any more sacred than an association with Cocoa string keypaths?
>>> 
>>> 
>>> Lots of languages use single quotes for character literals; we may want to 
>>> bring them back for it.
>>> 
>>> - Doug
>> 
> 
> ___
> 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-0168: Multi-Line String Literals

[David Hart via swift-evolution]

>   • What is your evaluation of the proposal?

Strong +1. Of all the ideas and proposals for multi-line string literals, this 
version is my favourite. Supporting copy/pasting and easy editing of multi-line 
strings is so important that I’m very happy the continuation quotes idea for 
dismissed.

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

Oh yes!

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

It does for me.

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

It compares favourably.

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

Followed most discussions about multi-line strings.

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[David Hart via swift-evolution]

> On 6 Apr 2017, at 19:41, Jordan Rose via swift-evolution 
>  wrote:
> 
> Hi, -evolution. I’ve said this before, but I think this new proposal is a 
> terrible idea. It privileges types in a way that is damaging to the language.
> 
> [There isn't really anything new in my discussion below; everyone on-thread 
> is smart enough to have brought up these points already. But I wanted to go 
> on record about it, at least.]
> 
> The claimed problem with the current version of 'private' (let's call it 
> "scoped-private") is that it encourages developers to make monolithic type 
> declarations instead of using extensions. With the proposed new 
> interpretation (let's call it "extension-file-private"), there's a similar 
> problem: developers are encouraged to put everything in the original type 
> even when it may be more appropriate to
> 
> 1. Extend another type (e.g. converting initializers)
> 2. Use a helper type (a nested type always inherits the generic parameters of 
> its enclosing type)
> 3. Break a single protocol or class out into a hierarchy (subtyping should be 
> used sparingly but not never)

I don’t get that impression. Even with this proposal, fileprivate is readily 
available to share implementation details with other types in the file. I view 
this proposal’s version of private very similarly to private in other languages 
(extensions in the same file as the type feel like part of the type’s scope to 
me).

> Of course, one can always add an extension to access the 
> extension-file-private members from outside the type, but that just 
> underscores how little expressive power this level would actually have. These 
> are cases where 'fileprivate' is the correct tool for the job.

I don’t feel like this proposal reduces the usefulness of fileprivate, it just 
makes private more attractive more most cases (i.e., it’s not because public is 
a good soft-default that open is any less useful).

> I liked the original three levels of access (not a surprise to anyone, since 
> I was a primary designer), and one reason for that is that the access levels 
> are completely indepedent of the declarations you're writing. You can 
> organize your code in whatever way makes the most sense, and the access 
> levels will then help you enforce that organization. I do think SE-0025 
> should not have been accepted, that it does not add enough benefit given the 
> increase to complexity, but even scoped-private can be used as an 
> organizational feature that prevents you from making mistakes, and it still 
> offers a simple answer to where a declaration can be used.

Speaking for someone who uses extensions extensively, I’ve found very little 
use for private in my own code.

> The proposed extension-file-private exposes a declaration to an arbitrary 
> subset of the file it's in, because being within an extension of a type or 
> not is arbitrary with regards to code organization. Extensions are used 
> organizationally, but there's now no way to distinguish whether the private 
> members of this extension are related to the private members of that 
> extension, or whether they were supposed to be independent.
> 
> Everyone is acting like "fileprivate" is a problem. While we may not like the 
> name, it's still the right tool for the job. What else do you have in the 
> file that you're trying to protect?

If it’s the right tool for the job, then the goal of SE-0025 to make private 
the soft-default and file private used in rarer occasions have failed. And 
that’s how I see this proposal: as trying to fix this original goal.

> Let's not add a mishmash of a feature just because it's "practical" for some 
> uses.
> 
> Thanks for hearing me out,
> Jordan
> 
> P.S. I have a lot to say on the idea of "submodules", and the dozen different 
> things people want from them. I'll try to write that up later, so that people 
> can refer to it if/when we ever get around to discussing such features. But 
> it's not relevant right now.
> 
> ___
> 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-0168: Multi-Line String Literals

[Tony Allevato via swift-evolution]

On Thu, Apr 6, 2017 at 12:35 PM Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0168 "Multi-Line String Literals" begins now and runs
> through April 12, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.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/0167-swift-encoders.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?
>

+0.75. I think the language needs a good facility to support multi-line
string literals in code, and the Python triple-quote syntax is the cleanest
of all the ones I've used among various languages.

I would like to see some more detail/clarification in the proposal before I
could give it a full +1 though:

1. The proposal shows that double quotes don't need to be escaped in these
literals; similarly, string interpolation is supported with the usual
\(...) syntax. How is escaping of other characters handled within these
strings? Is it affected or not? If I include \n in my multi-line string,
does that insert a newline at that location, or is it the literal "\n"? (I
expect the former, but I'd like to see it spelled out.)

2. If I want to be terrible and include the literal """ in the content of
my string, how would I escape that? Is \"\"\" sufficient/the only way/the
right way? Does it make a difference if it's leading the line (with the
exception of whitespace) or in the middle of a line?

3. Deciding how much leading whitespace to strip based on the indentation
of the *closing* quotes seems a bit strange/magical to me, but I honestly
can't think of a cleaner way to do it. This at least makes the amount of
leading space something that I can explicitly control (and IDEs like Xcode
could color in the margin accordingly to make it clear how much of the
leading space is actually part of the string).



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

Yes. While Apple platforms can just load large strings from bundled
resources, that doesn't support string interpolation, and non-Apple
platforms can also benefit from this feature.



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

It lines up most closely with Python's multi-line strings, which I prefer
to shell-style heredocs with arbitrary begin-end tokens.



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

Read the proposal.


>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> -Joe
> 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-0168: Multi-Line String Literals

[Greg Parker via swift-evolution]

> On Apr 6, 2017, at 12:35 PM, Joe Groff  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> 
> 

> Long strings are strings delimited by """triple quotes""" that can contain 
> newlines and individual " characters without the need to escape them.

Are the set of backslash-escapes inside a long string identical to the set used 
in short strings? I assume that \" inside a long string is interpreted as an 
escaped double-quote; otherwise there would be no way to write """ inside a 
long string.


> To allow free formatting of the literal an indentation stripping operation is 
> applied whereby any whitespace characters in front of the closing delimiter 
> are removed from each of the lines in the literal. As part of this process 
> any initial linefeed is also removed. This allows the developer to paste 
> literal content directly into the string without modification. Some concern 
> has been expressed about could introduce confusion if the prefixing 
> indentation of each line does not contain the same whitespace characters, 
> though this can be checked for by a compiler warning.

To clarify, is this the intended algorithm? 
if the source code of the closing delimiter matches regex(\n\s+""") {
collect the sequence of whitespace characters between the newline and 
the delimiter
remove exactly that sequence of characters, if present, from the front 
of each source-code line after the line containing the opening delimiter
if a line does not start with those characters, emit a warning
}


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 6, 2017, at 3:05 PM, Matthew Johnson  wrote:
> 
> 
>> On Apr 6, 2017, at 1:21 PM, John McCall > > wrote:
>> 
>>> On Apr 6, 2017, at 2:12 PM, Matthew Johnson >> > wrote:
 On Apr 6, 2017, at 1:06 PM, John McCall > wrote:
 
> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  > wrote:
>> On Apr 6, 2017, at 12:32 PM, John McCall > > wrote:
>> 
>>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
 On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
 > wrote:
 
 The rationale for using the same syntax is that a KeyPath is an 
 unapplied property/subscript access. Even the multi-segment part of it 
 isn't necessarily dissimilar: I don't think it would be unreasonable 
 to imagine that \Foo.someMethod.someOtherMethod could work*, that'd 
 just be function composition after all.
 
 KeyPath : Properties/Subscripts :: Functions with a self argument : 
 Methods
 
David
 
 *not proposing this, haven't thought carefully about whether there are 
 edge cases I'm missing here, but I think the analogy holds
>>> 
>>> I alluded to this kind of thing in the earlier threads.  It would be 
>>> very cool to see this explored in the future.
>>> 
>>> I really like the latest draft and am eagerly anticipating Smart 
>>> KeyPaths being implemented.  Thank you for listening to feedback from 
>>> the community!
>>> 
>>> One possible future direction I have been wondering about is whether it 
>>> might be interesting to expose an anonymous type for each distinct key 
>>> path which would have static members for getting (and setting if 
>>> mutable) the value.  The types would inherit from the most specific 
>>> matching key path type included in this proposal.  This would allow us 
>>> pass key paths statically using the type system and therefore not 
>>> requiring any runtime overhead.  
>>> 
>>> I have experimented with this approach in some of my own code and it 
>>> looks like it would be a very promising approach aside from the 
>>> boilerplate required to write these types manually.  I have abandoned 
>>> this approach for now because of the boilerplate and because the 
>>> syntactic sugar of the key path shorthand in this proposal is too 
>>> attractive to pass up.  I would love to explore it again in the future 
>>> if key paths were to support this approach.
>> 
>> Our generics system does not require generic code to be de-genericized 
>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
>> order to be run.  The generic code for applying a value of an unknown 
>> key-path type would look exactly like the non-generic code for applying 
>> a dynamic key-path type.  To get a runtime benefit, the compiler would 
>> have to de-genericize all the code between the function that formed the 
>> concrete key path and the function that applied it.  If the compiler can 
>> do that, it can also specialize that code for a known key path argument, 
>> the same way that it can specialize a function for a known function 
>> argument.  So there's no point.
> 
> Thanks for the reply John.  There may not be any additional optimization 
> opportunities in terms of code generation when using the key path but 
> wouldn’t it save on storage and reference counting related to key path 
> value?
 
 If you're specializing all the way down, any sort of boxing should be 
 possible to eliminate as well.
 
 If you mean in unspecialized code, well, I'm not entirely sure what 
 representation Joe is using, but I would assume that the fast path — where 
 a key path doesn't capture anything — does not require any allocation.  In 
 that sense, there's a strong parallel with how we represent functions: 
 yes, avoiding an extra allocation would be nice, but if you're willing to 
 accept an occasional allocation in more complex cases, there are also a 
 lot of benefits from being able to always give the type a concrete, 
 fixed-size representation.
>>> 
>>> Key paths in this proposal are classes which require storage of the pointer 
>>> as well as reference counting unless there is special of key path values.  
>>> Is something like that planned?  I could imagine some kind of tagged 
>>> pointer might be possible but I can’t imagine 

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Joe Groff via swift-evolution]

Hello Swift community,

The review of SE-0168 "Multi-Line String Literals" begins now and runs through 
April 12, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.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/0167-swift-encoders.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,

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Adam Knight via swift-evolution]

On Apr 6, 2017, at 1:17 PM, Jordan Rose via swift-evolution 
 wrote:
> 
>> On Apr 6, 2017, at 11:10, Vladimir.S  wrote:
>> 
>> On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:
>>> Hi, -evolution. I’ve said this before, but *I think this new proposal is a
>>> terrible idea*. It privileges types in a way that is damaging to the 
>>> language.
>>> 
>>> [There isn't really anything new in my discussion below; everyone on-thread
>>> is smart enough to have brought up these points already. But I wanted to go
>>> on record about it, at least.]
>> 
>> Thank you for sharing your opinion regarding this subject.
>> Do I understand correctly, that *you* propose to just revert access levels 
>> and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and 
>> rename 'fileprivate'->'private')
>> Or do you support to leave current 'scoped-private' under another name?
> 
> Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we 
> named the two levels "private" and "fileprivate", though I wish we hadn't; 
> and now there is lots of existing code relying on that, and it would be mean 
> and capricious to force people to change that code when they migrated to 
> Swift 4. I don't like where we ended up but Swift does not exist in a vacuum.

I think it neither mean nor capricious *if this is the last change we are ever 
going to do here*.  We need to get it right, even if there’s a breaking source 
change.  There’s a future-looking responsibility that is greater than the 
promises of minimal changes in the next version.  If we are locking ourselves 
in to this, then let’s fix it once and for all.  Or at least get damned close.  
If ’25 was a mistake then stand up, apologize, and fix it right.

The handcuffs are effectively self-inflicted.  We can judge for ourselves if we 
actually need to be wearing them or if, for the greater good, we pop out of 
them for a moment and Do The Right Thing.

IMO, there is a case to be had for:
* Things truly private to a type (eg. a seek index that must be changed in step 
with buffer data and metadata)
* Things private to a set of related types in one file (eg. every case in C 
where you didn’t put something in the header)
* Things private to a type and extensions to it (eg. a count of characters in a 
string; extensions might be allowed to change this)
* Things private to a module (most everything else).
* Things others can override (subclasses, etc.).

Right now we have identifiers for most of these.  What they’re called or when 
we use them is for another discussion; this is one of capability and need.  The 
question is: does the language support clean code for all common use cases?

Lacking a proper “private” that is tightly-scoped to the type it’s defined in 
would make that a resounding No.  Private means private, not Private But 
Everyone In The Room Can See It And Also Some People Near The Window.  That’s 
something else.

Reading this discussion for the past few days, I get the sense that no one has 
really bothered to define the question properly.  What are we trying to solve, 
specifically?  For whom?  What does that user expect?  What are we trying to 
avoid? To succeed with?  I see a lot of people talking about how they use 
things today and want to use them tomorrow, but what is the community goal 
here?  Can it be stated in one or two sentences?

— Adam

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 1:21 PM, John McCall  wrote:
> 
>> On Apr 6, 2017, at 2:12 PM, Matthew Johnson > > wrote:
>>> On Apr 6, 2017, at 1:06 PM, John McCall >> > wrote:
>>> 
 On Apr 6, 2017, at 1:41 PM, Matthew Johnson > wrote:
> On Apr 6, 2017, at 12:32 PM, John McCall  > wrote:
> 
>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>>> > wrote:
>>> 
>>> The rationale for using the same syntax is that a KeyPath is an 
>>> unapplied property/subscript access. Even the multi-segment part of it 
>>> isn't necessarily dissimilar: I don't think it would be unreasonable to 
>>> imagine that \Foo.someMethod.someOtherMethod could work*, that'd just 
>>> be function composition after all.
>>> 
>>> KeyPath : Properties/Subscripts :: Functions with a self argument : 
>>> Methods
>>> 
>>> David
>>> 
>>> *not proposing this, haven't thought carefully about whether there are 
>>> edge cases I'm missing here, but I think the analogy holds
>> 
>> I alluded to this kind of thing in the earlier threads.  It would be 
>> very cool to see this explored in the future.
>> 
>> I really like the latest draft and am eagerly anticipating Smart 
>> KeyPaths being implemented.  Thank you for listening to feedback from 
>> the community!
>> 
>> One possible future direction I have been wondering about is whether it 
>> might be interesting to expose an anonymous type for each distinct key 
>> path which would have static members for getting (and setting if 
>> mutable) the value.  The types would inherit from the most specific 
>> matching key path type included in this proposal.  This would allow us 
>> pass key paths statically using the type system and therefore not 
>> requiring any runtime overhead.  
>> 
>> I have experimented with this approach in some of my own code and it 
>> looks like it would be a very promising approach aside from the 
>> boilerplate required to write these types manually.  I have abandoned 
>> this approach for now because of the boilerplate and because the 
>> syntactic sugar of the key path shorthand in this proposal is too 
>> attractive to pass up.  I would love to explore it again in the future 
>> if key paths were to support this approach.
> 
> Our generics system does not require generic code to be de-genericized 
> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
> order to be run.  The generic code for applying a value of an unknown 
> key-path type would look exactly like the non-generic code for applying a 
> dynamic key-path type.  To get a runtime benefit, the compiler would have 
> to de-genericize all the code between the function that formed the 
> concrete key path and the function that applied it.  If the compiler can 
> do that, it can also specialize that code for a known key path argument, 
> the same way that it can specialize a function for a known function 
> argument.  So there's no point.
 
 Thanks for the reply John.  There may not be any additional optimization 
 opportunities in terms of code generation when using the key path but 
 wouldn’t it save on storage and reference counting related to key path 
 value?
>>> 
>>> If you're specializing all the way down, any sort of boxing should be 
>>> possible to eliminate as well.
>>> 
>>> If you mean in unspecialized code, well, I'm not entirely sure what 
>>> representation Joe is using, but I would assume that the fast path — where 
>>> a key path doesn't capture anything — does not require any allocation.  In 
>>> that sense, there's a strong parallel with how we represent functions: yes, 
>>> avoiding an extra allocation would be nice, but if you're willing to accept 
>>> an occasional allocation in more complex cases, there are also a lot of 
>>> benefits from being able to always give the type a concrete, fixed-size 
>>> representation.
>> 
>> Key paths in this proposal are classes which require storage of the pointer 
>> as well as reference counting unless there is special of key path values.  
>> Is something like that planned?  I could imagine some kind of tagged pointer 
>> might be possible but I can’t imagine how you would eliminate the need to 
>> store a word.  It’s not that much overhead but it would still be nice to be 
>> able to avoid it when all we’re doing is passing a stateless function 
>> 

Re: [swift-evolution] Type-based ‘private’ access within a file

[Vladimir.S via swift-evolution]

On 06.04.2017 21:40, Jordan Rose via swift-evolution wrote:



On Apr 6, 2017, at 11:35, Nevin Brackett-Rozinsky via swift-evolution
> wrote:

On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution
> wrote:


We accepted SE-0025, though I wish we hadn't; we named the two levels
"private" and "fileprivate", though I wish we hadn't; and now there
is lots of existing code relying on that, and it would be mean and
capricious to force people to change that code when they migrated to
Swift 4. I don't like where we ended up but Swift does not exist in a
vacuum.


I hardly think it is “mean” or “capricious” to provide a *fully automated
migrator* to make the keywords better.

The discussion of SE-0159 reached a near-consensus that the access levels
should be spelled “private” and “scoped”.

I was shocked and dismayed that the core team did anything other than
enthusiastically adopt that resolution.


I didn't get the sense of a "near-consensus", but one concern that I don't
remember being brought up on list was that it would make mixing Swift 3 and
Swift 4 much more confusing (including when dealing with sample code
snippets found online).


Probably this is why core team should raise a draft/pitch/review directly 
for that subject(renaming) and got the community's reply on it?

(I believe the response will be very positive)

As for mixing Swift3 and Swift4 and other drawbacks, they also could be 
discussed during the review of concrete subject(renaming) and IMO good 
solution can be found or decided that such drawbacks worth of these 
changes. At the end, this should make Swift better for long period of time, 
should fix the mistake, should(as I can see it currently) fits well with 
submodules, but drawbacks(other solutions also has their own drawbacks) 
will exist only during the adoption period. Especially given this is "the 
last chance to change anything in access modifiers".




Jordan



___
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-0164: Remove final support in protocol extensions

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md
 
]

+1 from me, for all the reasons in the proposal. 'final' doesn't mean anything 
in protocol extensions right now—it is literally ignored—so regardless of the 
actual justified confusion around extension members that satisfy requirements 
and those that don't, we should go forward with removing 'final'.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md
 
]

> On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution 
>  wrote:
> 
> The review of SE-0164 "Remove final support in protocol extensions"
> 
>> What is your evaluation of the proposal?
> The present situation isn't great. People get confused about which method 
> will called with protocol extensions. Seems like every week there is a 
> variation on this confusion on Swift Users mailing list. Therefore something 
> needs to be done. 
> 
> However I am not keen on this proposal since it makes behaviour inconsistent 
> between methods in protocol extensions, classes, and structs. 
> 
> I think a better solution would be one of the following alternatives:
> 
>   1. Must use final and final means it cannot be overridden; or
>   2. If not final dispatches using a table like a class and if marked final 
> cannot be overridden and if marked dynamic uses obj-c dispatching; or
>   3. Must be marked dynamic and uses obj-c dispatching. 
> 
> My preference would be option 2 but I think any of the three is superior to 
> the present situation or the proposal. 

People have suggested all of these before, but none of them are obviously 
correct. It's true that we have a difference between extension members that 
satisfy requirements and those that don't, and that that confuses people. 
However, an extension-only member of one protocol can be used to satisfy the 
requirements of another protocol today, which is a tool for code reuse.

(I think we managed to convince everyone that it's just a bug that a protocol 
extension method that satisfies a requirement cannot be overridden in a 
subclass, so at least that isn't an issue on top of the rest of this.)

Oh, and we can't retroactively add members of a protocol extension to existing 
adopters, which is why protocol extension members cannot be @objc. There are 
limited circumstances where that would be safe, but that would be a separate 
proposal.

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Vladimir.S via swift-evolution]

On 06.04.2017 21:17, Jordan Rose wrote:



On Apr 6, 2017, at 11:10, Vladimir.S  wrote:

On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:

Hi, -evolution. I’ve said this before, but *I think this new
proposal is a terrible idea*. It privileges types in a way that is
damaging to the language.

[There isn't really anything new in my discussion below; everyone
on-thread is smart enough to have brought up these points already.
But I wanted to go on record about it, at least.]


Thank you for sharing your opinion regarding this subject. Do I
understand correctly, that *you* propose to just revert access levels
and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private'
and rename 'fileprivate'->'private') Or do you support to leave
current 'scoped-private' under another name?


Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we
named the two levels "private" and "fileprivate", though I wish we
hadn't; and now there is lots of existing code relying on that, and it
would be mean and capricious to force people to change that code when
they migrated to Swift 4. I don't like where we ended up but Swift does
not exist in a vacuum.


I see. Thank you for clarification.

I wonder, can't this be the situation that core team protects people 
"relying on that" when actually most(probably most, I don't know) people 
are asking "pleease.. rename this fileprivate to private back and keep 
'scoped' for those, who actually need Swift3 scoped-private, its the best 
solution, we are ready to change our code(actually just use 100% automatic 
rename) in Swift4"?
(Btw, probably one should prepare such 'official' proposal so community can 
provide response directly during its 'official' review?? I don't know. The 
situation is at least strange currently IMO: nobody likes current state, 
seems like we have the best solution for this, new official proposals looks 
like some workaround instead of right solution and IMO produces more 
confusion than even current state)


Waiting for your thoughts regarding submodules etc, as IMO keeping 
'fileprivate' keyword could be another one mistake we are making right now.





Jordan



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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Jordan Rose via swift-evolution]

> On Apr 6, 2017, at 11:35, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
> We accepted SE-0025, though I wish we hadn't; we named the two levels 
> "private" and "fileprivate", though I wish we hadn't; and now there is lots 
> of existing code relying on that, and it would be mean and capricious to 
> force people to change that code when they migrated to Swift 4. I don't like 
> where we ended up but Swift does not exist in a vacuum.
> 
> I hardly think it is “mean” or “capricious” to provide a *fully automated 
> migrator* to make the keywords better.
> 
> The discussion of SE-0159 reached a near-consensus that the access levels 
> should be spelled “private” and “scoped”.
> 
> I was shocked and dismayed that the core team did anything other than 
> enthusiastically adopt that resolution.

I didn't get the sense of a "near-consensus", but one concern that I don't 
remember being brought up on list was that it would make mixing Swift 3 and 
Swift 4 much more confusing (including when dealing with sample code snippets 
found online).

Jordan

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Nevin Brackett-Rozinsky via swift-evolution]

On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> We accepted SE-0025, though I wish we hadn't; we named the two levels
> "private" and "fileprivate", though I wish we hadn't; and now there is lots
> of existing code relying on that, and it would be mean and capricious to
> force people to change that code when they migrated to Swift 4. I don't
> like where we ended up but Swift does not exist in a vacuum.
>

I hardly think it is “mean” or “capricious” to provide a *fully automated
migrator* to make the keywords better.

The discussion of SE-0159 reached a near-consensus that the access levels
should be spelled “private” and “scoped”.

I was shocked and dismayed that the core team did anything other than
enthusiastically adopt that resolution.

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 6, 2017, at 2:12 PM, Matthew Johnson  wrote:
>> On Apr 6, 2017, at 1:06 PM, John McCall > > wrote:
>> 
>>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson >> > wrote:
 On Apr 6, 2017, at 12:32 PM, John McCall > wrote:
 
> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
> > wrote:
>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>> > wrote:
>> 
>> The rationale for using the same syntax is that a KeyPath is an 
>> unapplied property/subscript access. Even the multi-segment part of it 
>> isn't necessarily dissimilar: I don't think it would be unreasonable to 
>> imagine that \Foo.someMethod.someOtherMethod could work*, that'd just be 
>> function composition after all.
>> 
>> KeyPath : Properties/Subscripts :: Functions with a self argument : 
>> Methods
>> 
>>  David
>> 
>> *not proposing this, haven't thought carefully about whether there are 
>> edge cases I'm missing here, but I think the analogy holds
> 
> I alluded to this kind of thing in the earlier threads.  It would be very 
> cool to see this explored in the future.
> 
> I really like the latest draft and am eagerly anticipating Smart KeyPaths 
> being implemented.  Thank you for listening to feedback from the 
> community!
> 
> One possible future direction I have been wondering about is whether it 
> might be interesting to expose an anonymous type for each distinct key 
> path which would have static members for getting (and setting if mutable) 
> the value.  The types would inherit from the most specific matching key 
> path type included in this proposal.  This would allow us pass key paths 
> statically using the type system and therefore not requiring any runtime 
> overhead.  
> 
> I have experimented with this approach in some of my own code and it 
> looks like it would be a very promising approach aside from the 
> boilerplate required to write these types manually.  I have abandoned 
> this approach for now because of the boilerplate and because the 
> syntactic sugar of the key path shorthand in this proposal is too 
> attractive to pass up.  I would love to explore it again in the future if 
> key paths were to support this approach.
 
 Our generics system does not require generic code to be de-genericized 
 ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in 
 order to be run.  The generic code for applying a value of an unknown 
 key-path type would look exactly like the non-generic code for applying a 
 dynamic key-path type.  To get a runtime benefit, the compiler would have 
 to de-genericize all the code between the function that formed the 
 concrete key path and the function that applied it.  If the compiler can 
 do that, it can also specialize that code for a known key path argument, 
 the same way that it can specialize a function for a known function 
 argument.  So there's no point.
>>> 
>>> Thanks for the reply John.  There may not be any additional optimization 
>>> opportunities in terms of code generation when using the key path but 
>>> wouldn’t it save on storage and reference counting related to key path 
>>> value?
>> 
>> If you're specializing all the way down, any sort of boxing should be 
>> possible to eliminate as well.
>> 
>> If you mean in unspecialized code, well, I'm not entirely sure what 
>> representation Joe is using, but I would assume that the fast path — where a 
>> key path doesn't capture anything — does not require any allocation.  In 
>> that sense, there's a strong parallel with how we represent functions: yes, 
>> avoiding an extra allocation would be nice, but if you're willing to accept 
>> an occasional allocation in more complex cases, there are also a lot of 
>> benefits from being able to always give the type a concrete, fixed-size 
>> representation.
> 
> Key paths in this proposal are classes which require storage of the pointer 
> as well as reference counting unless there is special of key path values.  Is 
> something like that planned?  I could imagine some kind of tagged pointer 
> might be possible but I can’t imagine how you would eliminate the need to 
> store a word.  It’s not that much overhead but it would still be nice to be 
> able to avoid it when all we’re doing is passing a stateless function 
> reference.

Are you under the impression that run-time generics don't require passing extra 
pointers around?

John.

> 
>> 
>>> As a secondary question, wouldn’t this be similar to the difference between 
>>> 

Re: [swift-evolution] Type-based ‘private’ access within a file

[Jordan Rose via swift-evolution]

> On Apr 6, 2017, at 11:10, Vladimir.S  wrote:
> 
> On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:
>> Hi, -evolution. I’ve said this before, but *I think this new proposal is a
>> terrible idea*. It privileges types in a way that is damaging to the 
>> language.
>> 
>> [There isn't really anything new in my discussion below; everyone on-thread
>> is smart enough to have brought up these points already. But I wanted to go
>> on record about it, at least.]
> 
> Thank you for sharing your opinion regarding this subject.
> Do I understand correctly, that *you* propose to just revert access levels 
> and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and 
> rename 'fileprivate'->'private')
> Or do you support to leave current 'scoped-private' under another name?

Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we named 
the two levels "private" and "fileprivate", though I wish we hadn't; and now 
there is lots of existing code relying on that, and it would be mean and 
capricious to force people to change that code when they migrated to Swift 4. I 
don't like where we ended up but Swift does not exist in a vacuum.

Jordan

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brad Hilton via swift-evolution]

Yes. I'd prefer to keep unapplied method references the same and do
properties the same way IMHO.

On Thu, Apr 6, 2017 at 12:05 PM, Douglas Gregor  wrote:

>
> On Apr 6, 2017, at 11:01 AM, Brad Hilton  wrote:
>
> -1. Not a huge fan of the back slash. Doesn’t make sense considering we
> can refer to unapplied method references without the backslash. Maybe we
> can settle on some unified syntax for both? How about Person.name.get /
> Person.name.set for getter/setter references.
>
>
> Did you read the core team’s commentary on unapplied method references?
>
> https://lists.swift.org/pipermail/swift-evolution-
> announce/2017-April/000342.html pipermail/swift-evolution-announce/2017-April/000342.html>
>
> ?
> - Doug
>
>
> Hello Swift community,
>
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for
> Swift" begins now and runs through April 9, 2017. The revised proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0161-key-paths.md swift-evolution/blob/master/proposals/0161-key-paths.md>
> The core team’s feedback from the first review of this proposal can be
> viewed at:
>
> https://lists.swift.org/pipermail/swift-evolution-
> announce/2017-April/000342.html pipermail/swift-evolution-announce/2017-April/000342.html>
> 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<
> 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/0161-key-paths.md evolution/blob/master/proposals/0161-key-paths.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<
> 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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 1:06 PM, John McCall  wrote:
> 
>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson > > wrote:
>>> On Apr 6, 2017, at 12:32 PM, John McCall >> > wrote:
>>> 
 On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
 > wrote:
> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
> > wrote:
> 
> The rationale for using the same syntax is that a KeyPath is an unapplied 
> property/subscript access. Even the multi-segment part of it isn't 
> necessarily dissimilar: I don't think it would be unreasonable to imagine 
> that \Foo.someMethod.someOtherMethod could work*, that'd just be function 
> composition after all.
> 
> KeyPath : Properties/Subscripts :: Functions with a self argument : 
> Methods
> 
>   David
> 
> *not proposing this, haven't thought carefully about whether there are 
> edge cases I'm missing here, but I think the analogy holds
 
 I alluded to this kind of thing in the earlier threads.  It would be very 
 cool to see this explored in the future.
 
 I really like the latest draft and am eagerly anticipating Smart KeyPaths 
 being implemented.  Thank you for listening to feedback from the community!
 
 One possible future direction I have been wondering about is whether it 
 might be interesting to expose an anonymous type for each distinct key 
 path which would have static members for getting (and setting if mutable) 
 the value.  The types would inherit from the most specific matching key 
 path type included in this proposal.  This would allow us pass key paths 
 statically using the type system and therefore not requiring any runtime 
 overhead.  
 
 I have experimented with this approach in some of my own code and it looks 
 like it would be a very promising approach aside from the boilerplate 
 required to write these types manually.  I have abandoned this approach 
 for now because of the boilerplate and because the syntactic sugar of the 
 key path shorthand in this proposal is too attractive to pass up.  I would 
 love to explore it again in the future if key paths were to support this 
 approach.
>>> 
>>> Our generics system does not require generic code to be de-genericized 
>>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order 
>>> to be run.  The generic code for applying a value of an unknown key-path 
>>> type would look exactly like the non-generic code for applying a dynamic 
>>> key-path type.  To get a runtime benefit, the compiler would have to 
>>> de-genericize all the code between the function that formed the concrete 
>>> key path and the function that applied it.  If the compiler can do that, it 
>>> can also specialize that code for a known key path argument, the same way 
>>> that it can specialize a function for a known function argument.  So 
>>> there's no point.
>> 
>> Thanks for the reply John.  There may not be any additional optimization 
>> opportunities in terms of code generation when using the key path but 
>> wouldn’t it save on storage and reference counting related to key path value?
> 
> If you're specializing all the way down, any sort of boxing should be 
> possible to eliminate as well.
> 
> If you mean in unspecialized code, well, I'm not entirely sure what 
> representation Joe is using, but I would assume that the fast path — where a 
> key path doesn't capture anything — does not require any allocation.  In that 
> sense, there's a strong parallel with how we represent functions: yes, 
> avoiding an extra allocation would be nice, but if you're willing to accept 
> an occasional allocation in more complex cases, there are also a lot of 
> benefits from being able to always give the type a concrete, fixed-size 
> representation.

Key paths in this proposal are classes which require storage of the pointer as 
well as reference counting unless there is special of key path values.  Is 
something like that planned?  I could imagine some kind of tagged pointer might 
be possible but I can’t imagine how you would eliminate the need to store a 
word.  It’s not that much overhead but it would still be nice to be able to 
avoid it when all we’re doing is passing a stateless function reference.

> 
>> As a secondary question, wouldn’t this be similar to the difference between 
>> generics and existentials?  In theory the same optimizations could be 
>> applied but in practice they are not always right now.  Is the plan to 
>> eventually put existentials on equal footing in terms of optimization?
> 
> Eventually, yes, I think that's something we'd like make sure we can do.
> 
> John.
> 
>> 
>>> 

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Joe Groff via swift-evolution]

> On Apr 6, 2017, at 11:06 AM, John McCall  wrote:
> 
>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  wrote:
>>> On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
>>> 
 On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
  wrote:
> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>  wrote:
> 
> The rationale for using the same syntax is that a KeyPath is an unapplied 
> property/subscript access. Even the multi-segment part of it isn't 
> necessarily dissimilar: I don't think it would be unreasonable to imagine 
> that \Foo.someMethod.someOtherMethod could work*, that'd just be function 
> composition after all.
> 
> KeyPath : Properties/Subscripts :: Functions with a self argument : 
> Methods
> 
>   David
> 
> *not proposing this, haven't thought carefully about whether there are 
> edge cases I'm missing here, but I think the analogy holds
 
 I alluded to this kind of thing in the earlier threads.  It would be very 
 cool to see this explored in the future.
 
 I really like the latest draft and am eagerly anticipating Smart KeyPaths 
 being implemented.  Thank you for listening to feedback from the community!
 
 One possible future direction I have been wondering about is whether it 
 might be interesting to expose an anonymous type for each distinct key 
 path which would have static members for getting (and setting if mutable) 
 the value.  The types would inherit from the most specific matching key 
 path type included in this proposal.  This would allow us pass key paths 
 statically using the type system and therefore not requiring any runtime 
 overhead.  
 
 I have experimented with this approach in some of my own code and it looks 
 like it would be a very promising approach aside from the boilerplate 
 required to write these types manually.  I have abandoned this approach 
 for now because of the boilerplate and because the syntactic sugar of the 
 key path shorthand in this proposal is too attractive to pass up.  I would 
 love to explore it again in the future if key paths were to support this 
 approach.
>>> 
>>> Our generics system does not require generic code to be de-genericized 
>>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order 
>>> to be run.  The generic code for applying a value of an unknown key-path 
>>> type would look exactly like the non-generic code for applying a dynamic 
>>> key-path type.  To get a runtime benefit, the compiler would have to 
>>> de-genericize all the code between the function that formed the concrete 
>>> key path and the function that applied it.  If the compiler can do that, it 
>>> can also specialize that code for a known key path argument, the same way 
>>> that it can specialize a function for a known function argument.  So 
>>> there's no point.
>> 
>> Thanks for the reply John.  There may not be any additional optimization 
>> opportunities in terms of code generation when using the key path but 
>> wouldn’t it save on storage and reference counting related to key path value?
> 
> If you're specializing all the way down, any sort of boxing should be 
> possible to eliminate as well.
> 
> If you mean in unspecialized code, well, I'm not entirely sure what 
> representation Joe is using, but I would assume that the fast path — where a 
> key path doesn't capture anything — does not require any allocation.  In that 
> sense, there's a strong parallel with how we represent functions: yes, 
> avoiding an extra allocation would be nice, but if you're willing to accept 
> an occasional allocation in more complex cases, there are also a lot of 
> benefits from being able to always give the type a concrete, fixed-size 
> representation.

Yeah, I've set up the implementation so that literal key paths get emitted as 
global objects that don't need allocation, and shouldn't need refcounting once 
the runtime gains support for inert objects. I also set up the SIL 
representation for these in a way that we'll eventually be able to do 
high-level optimization, so that when we see a literal key path applied to a 
concrete base, we can lower the key path application into direct projections on 
the base value. Since everything is implemented using opaque classes now, there 
isn't much opportunity for specialization, but I think high-level optimizations 
are probably a better fit for the common cases.

-Joe

>> As a secondary question, wouldn’t this be similar to the difference between 
>> generics and existentials?  In theory the same optimizations could be 
>> applied but in practice they are not always right now.  Is the plan to 
>> eventually put existentials on equal footing in terms of optimization?
> 
> Eventually, yes, I think 

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
through April 12, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Vladimir.S via swift-evolution]

On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:

Hi, -evolution. I’ve said this before, but *I think this new proposal is a
terrible idea*. It privileges types in a way that is damaging to the language.

[There isn't really anything new in my discussion below; everyone on-thread
is smart enough to have brought up these points already. But I wanted to go
on record about it, at least.]


Thank you for sharing your opinion regarding this subject.
Do I understand correctly, that *you* propose to just revert access levels 
and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and 
rename 'fileprivate'->'private')

Or do you support to leave current 'scoped-private' under another name?

Vladimir.



The claimed problem with the current version of 'private' (let's call it
"scoped-private") is that it encourages developers to make monolithic type
declarations instead of using extensions. With the proposed new
interpretation (let's call it "extension-file-private"), there's a similar
problem: developers are encouraged to put everything in the original type
even when it may be more appropriate to

1. Extend another type (e.g. converting initializers)
2. Use a helper type (a nested type always inherits the generic parameters
of its enclosing type)
3. Break a single protocol or class out into a hierarchy (subtyping should
be used /sparingly/ but not /never)/

Of course, one can always add an extension to access the
extension-file-private members from outside the type, but that just
underscores how little expressive power this level would actually have.
These are cases where 'fileprivate' is the /correct/ tool for the job.

I liked the original three levels of access (not a surprise to anyone,
since I was a primary designer), and one reason for that is that the access
levels are /completely indepedent/ of the declarations you're writing. You
can organize your code in whatever way makes the most sense, and the access
levels will then help you enforce that organization. I do think SE-0025
should not have been accepted, that it does not add enough benefit given
the increase to complexity, but even scoped-private can be used as an
organizational feature that prevents you from making mistakes, and it still
offers a simple answer to where a declaration can be used.

The proposed extension-file-private exposes a declaration to an arbitrary
subset of the file it's in, because being within an extension of a type or
not is arbitrary with regards to code organization. Extensions /are/ used
organizationally, but there's now no way to distinguish whether the private
members of /this/ extension are related to the private members
of /that/ extension, or whether they were supposed to be independent.

Everyone is acting like "fileprivate" is a problem. While we may not like
the name, /it's still the right tool for the job./ What else do you have in
the file that you're trying to protect?

Let's not add a mishmash of a feature just because it's "practical" for
some uses.

Thanks for hearing me out,
Jordan

P.S. I have a /lot/ to say on the idea of "submodules", and the dozen
different things people want from them. I'll try to write that up later, so
that people can refer to it if/when we ever get around to discussing such
features. But it's not relevant right now.



___
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] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Note that this proposal is closely related to (and dependent on) SE-0166: Swift 
Archival & Serialization 
.
 Please read and review that proposal as well!

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/0167-swift-encoders.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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 6, 2017, at 1:41 PM, Matthew Johnson  wrote:
>> On Apr 6, 2017, at 12:32 PM, John McCall > > wrote:
>> 
>>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
 On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
 > wrote:
 
 The rationale for using the same syntax is that a KeyPath is an unapplied 
 property/subscript access. Even the multi-segment part of it isn't 
 necessarily dissimilar: I don't think it would be unreasonable to imagine 
 that \Foo.someMethod.someOtherMethod could work*, that'd just be function 
 composition after all.
 
 KeyPath : Properties/Subscripts :: Functions with a self argument : Methods
 
David
 
 *not proposing this, haven't thought carefully about whether there are 
 edge cases I'm missing here, but I think the analogy holds
>>> 
>>> I alluded to this kind of thing in the earlier threads.  It would be very 
>>> cool to see this explored in the future.
>>> 
>>> I really like the latest draft and am eagerly anticipating Smart KeyPaths 
>>> being implemented.  Thank you for listening to feedback from the community!
>>> 
>>> One possible future direction I have been wondering about is whether it 
>>> might be interesting to expose an anonymous type for each distinct key path 
>>> which would have static members for getting (and setting if mutable) the 
>>> value.  The types would inherit from the most specific matching key path 
>>> type included in this proposal.  This would allow us pass key paths 
>>> statically using the type system and therefore not requiring any runtime 
>>> overhead.  
>>> 
>>> I have experimented with this approach in some of my own code and it looks 
>>> like it would be a very promising approach aside from the boilerplate 
>>> required to write these types manually.  I have abandoned this approach for 
>>> now because of the boilerplate and because the syntactic sugar of the key 
>>> path shorthand in this proposal is too attractive to pass up.  I would love 
>>> to explore it again in the future if key paths were to support this 
>>> approach.
>> 
>> Our generics system does not require generic code to be de-genericized 
>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order 
>> to be run.  The generic code for applying a value of an unknown key-path 
>> type would look exactly like the non-generic code for applying a dynamic 
>> key-path type.  To get a runtime benefit, the compiler would have to 
>> de-genericize all the code between the function that formed the concrete key 
>> path and the function that applied it.  If the compiler can do that, it can 
>> also specialize that code for a known key path argument, the same way that 
>> it can specialize a function for a known function argument.  So there's no 
>> point.
> 
> Thanks for the reply John.  There may not be any additional optimization 
> opportunities in terms of code generation when using the key path but 
> wouldn’t it save on storage and reference counting related to key path value?

If you're specializing all the way down, any sort of boxing should be possible 
to eliminate as well.

If you mean in unspecialized code, well, I'm not entirely sure what 
representation Joe is using, but I would assume that the fast path — where a 
key path doesn't capture anything — does not require any allocation.  In that 
sense, there's a strong parallel with how we represent functions: yes, avoiding 
an extra allocation would be nice, but if you're willing to accept an 
occasional allocation in more complex cases, there are also a lot of benefits 
from being able to always give the type a concrete, fixed-size representation.

> As a secondary question, wouldn’t this be similar to the difference between 
> generics and existentials?  In theory the same optimizations could be applied 
> but in practice they are not always right now.  Is the plan to eventually put 
> existentials on equal footing in terms of optimization?

Eventually, yes, I think that's something we'd like make sure we can do.

John.

> 
>> 
>> John.
>> 
>>> 
>>> Matthew
>>> 
 
> On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution 
> > wrote:
> 
> I too find the backslash odd, as it’s usually of course used to escape 
> something.
> 
> What about three periods?
> 
> let firstFriendsNameKeyPath = Person...friends[0].name
> print(luke[keyPath: ...friends[0].name])
> 
> 
> I also find wanting to use the same syntax for unapplied methods strange, 
> as they would product two totally different things: one a key path value, 
> the other a function.
> 
> Patrick
> On Thu, 6 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 11:01 AM, Brad Hilton  wrote:
> 
> -1. Not a huge fan of the back slash. Doesn’t make sense considering we can 
> refer to unapplied method references without the backslash. Maybe we can 
> settle on some unified syntax for both? How about Person.name.get / 
> Person.name.set for getter/setter references.

Did you read the core team’s commentary on unapplied method references?


https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
 


?
- Doug

> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>> The core team’s feedback from the first review of this proposal can be 
>> viewed at:
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>> 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/0161-key-paths.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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brad Hilton via swift-evolution]

-1. Not a huge fan of the back slash. Doesn’t make sense considering we can 
refer to unapplied method references without the backslash. Maybe we can settle 
on some unified syntax for both? How about Person.name.get / Person.name.set 
for getter/setter references.

> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be viewed 
> at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> 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/0161-key-paths.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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Sean Heber via swift-evolution]

If single quotes are out, then I would suggest requiring a parenthesis. I guess 
I just don’t like that it’s unbounded and I’m sure that’s some kind of personal 
preference thing, but what isn’t around here? :P

For example:

\(Person.name)

instead of:

\Person.name

I think an argument could be made that the pattern of \(..) in Swift could more 
or less come to mean, “escape this context” which is sort of how it is in 
string interpolation - you’re saying “evaluate this part as if it wasn’t 
embedded inside this string construct." A keypath is similar because it’s like, 
“one level higher”, so to reference a keypath, you have to “escape” from your 
current context - which is the source code itself - in order to express it. 
Sorta?

l8r
Sean


> On Apr 6, 2017, at 11:37 AM, Douglas Gregor  wrote:
> 
> 
>> On Apr 6, 2017, at 9:31 AM, Sean Heber  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor  wrote:
>>> 
 
 On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
  wrote:
 
 I agree, there's an analogy between strings and key paths, and in that 
 regards the single quote would make sense.  I would not complain.  
>>> 
>>> The only analogy between strings and key-paths is that the existing Cocoa 
>>> APIs for key-paths use strings. That’s not an analogy to hang language 
>>> syntax on, because it’s relevance will fade quickly. 
>> 
>> Why would it fade quickly? Do we expect the concept of keypaths to go away 
>> over time? If so, why are we even designing a syntax for keypaths?
> 
> The link between key-paths and strings will go away over time. The *only* 
> reason anyone associates strings with keypaths is because Cocoa’s current 
> key-paths are string-based. This proposal makes any string representation of 
> key-paths an implementation detail that could be used for interoperability 
> with Cocoa’s current system. There is no reason for a type-unsafe string 
> representation to ever be in the user model.
> 
> 
>>> The core team discussed single quotes, and decided that we want to save 
>>> them for something in the string/character realm.
>> 
>> Are they to be saved for something specific or is this just because a lot of 
>> languages use single quotes for character literals? Why is this association 
>> any more sacred than an association with Cocoa string keypaths?
> 
> 
> Lots of languages use single quotes for character literals; we may want to 
> bring them back for it.
> 
>   - Doug
> 

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Ted F.A. van Gaalen via swift-evolution]

Dear Colleague Travellers In Turbulent And Interesting Digital Times :) 

Sorry, that I have not read all other opinions on this thread thoroughly,
there's so much of it which confuses me. The sheer volume of this traffic gives 
me the impression that scope management is Swift is fundamentally wrong.  

As written before on another thread, namely that currently all members of a 
class or struct are exposed by default, due to having a default scope of  
‘internal’  and are therefore accessible in the entire module is imho very bad 
and unstructured programming practice.  (e.g. why are the members of a function 
(correctly) have private scope and classes and struct don't have this? Isn't 
that very inconsistent? 

In Swift there should be lexical scope only, I think,  as in most procedural / 
OOP programming languages.  This is a very simple and above all consistent 
rule, easy to understand for everyone, even rookies, and also would make 
programming in Swift more consistent and reliable. (Maybe it would even 
simplify the compiler processing more or less, but I have not enough knowledge 
about this.)

Having consistent lexical scope only, with no exceptions, would in almost all 
cases eliminate the necessity to explicitly use the keywords “private” and 
“fileprivate”. . . The latter imho is really awkward, solid proof of the 
inconsistency with current Swift scoping, because the scope of what's in a file 
is treated differently that that of other coding scopes, like class, struct, 
function or any other {} block... isn't it? 

So I'd prefer consistent lexical scope only, that is, unless overruled by a 
scope modifier, an item should be available only within the code level/unit 
where it is declared.

However, I assume that it is too late to correct this, as it would turn the 
existing code base of all Swift users completely upside down, wouldn't it?
making it necessary for the ones supporting this to flee to another universe to 
avoid repercussions... the very idea...

Kind Regards
TedvG
www.tedvg.com



> Date: Wed, 5 Apr 2017 20:34:27 -0500
> From: Matthew Johnson >
> To: Colin Barrett  >
> Cc: swift-evolution  >
> Subject: Re: [swift-evolution] Type-based ‘private’ access within
>   a file
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On Apr 5, 2017, at 7:11 PM, Colin Barrett via swift-evolution 
>> > wrote:
>> 
>> I'm broadly in favor of this.
>> 
>> On Mon, Apr 3, 2017 at 2:35 PM Douglas Gregor via swift-evolution 
>> > > >> wrote:
>> Hello Swift Community,
>> 
>> In rejecting SE-0159 
>> >  
>> >,
>>  the core team described a potential direction we would like to investigate 
>> for “private” access control that admits a limited form of type-based access 
>> control within files. The core team is seeking some discussion here and a 
>> motivated volunteer to put together a proposal along these lines for review 
>> in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s 
>> sure this is the right direction to go… but it appears promising and we 
>> would *love* to be able to settle the access-control issue.
>> 
>> The design, specifically, is that a “private” member declared within a type 
>> “X” or an extension thereof would be accessible from:
>> 
>>  * An extension of “X” in the same file
>>  * The definition of “X”, if it occurs in the same file
>>  * A nested type (or extension thereof) of one of the above that occurs 
>> in the same file
>> 
>> This design has a number of apparent benefits:
>>  + “private” becomes the right default for “less than whole module” 
>> visibility, and aligns well with Swift coding style that divides a type’s 
>> definition into a number of extensions.
>>  + “fileprivate” remains for existing use cases, but now it’s use it 
>> more rare, which has several advantages:
>>  + It fits well with the "progressive disclosure” philosophy 
>> behind Swift: you can use public/internal/private for a while before 
>> encountering and having to learn about “fileprivate”   (note: we thought 
>> this was going to be true of SE-0025 
>> >  
>> >,

Re: [swift-evolution] Make class and struct members private by default / Type-Based access

[Ted F.A. van Gaalen via swift-evolution]

Hi David

jikes! You’re right, total blunder. I should do my homework better :o) 
I have been using Java before, be it with the assumption that it had private 
scope
for class members, because of the line of PLs I was using before I started 
using Java
I went on programming assuming that it had, which never led to scope conflicts 
because
of programming consequently within this assumption, so, I never noticed this. 
:o) 
 
This is because in most PLs in my historyFortran -> Cobol-> PL/1 -> Pascal 
-> Modula ->
C -> C++ consistent lexical scope is present (since ca. 1960 with Algol)   
After that C# (nice language too, which has it)  and ObjC (which hasn’t) and 
Smalltalk for many years
which has (needs) no scope modifiers at all (in a class all methods are not 
private
but variables are.) 

Sorry for the incorrect assumptions. 
Nevertheless I hold on to my point of view that there should be lexical scope 
only in Swift,
(as Swift being a procedural/OOP language) 
however rigidly enforcing this in Swift 4 would be probably too much of a 
change now.

I do not understand what is so hard on private-by-default? (that is, if used
this way right from the beginning of writing an application, 
(provided a program language is set up that way)

TedvG
www.tedvg.com
> On 4. Apr 2017, at 22:17, David Waite  wrote:
> 
> 
>> On Apr 4, 2017, at 7:07 AM, Ted F.A. van Gaalen via swift-evolution 
>> > wrote:
>> 
>> Hi Xiaodi,
>> 
>> that currently all members of a class or struct are exposed by default by 
>> having
>> a default scope of  ‘internal’  and are therefore accessible in the entire 
>> module
>> is imho very bad unstructured programming practice. 
>> 
>> In no other OOP language it is implemented
>> that way.. 
> 
> I think you may be forgetting Java (and Ruby, and Python, and Go, and 
> Objective-C, and…)
> 
> In my experience , the hard-private-by-default comes from C++ and heavily 
> influenced languages like C# and Rust.
> 
> -DW

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Matthew Johnson via swift-evolution]

> On Apr 6, 2017, at 12:32 PM, John McCall  wrote:
> 
>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>>> > wrote:
>>> 
>>> The rationale for using the same syntax is that a KeyPath is an unapplied 
>>> property/subscript access. Even the multi-segment part of it isn't 
>>> necessarily dissimilar: I don't think it would be unreasonable to imagine 
>>> that \Foo.someMethod.someOtherMethod could work*, that'd just be function 
>>> composition after all.
>>> 
>>> KeyPath : Properties/Subscripts :: Functions with a self argument : Methods
>>> 
>>> David
>>> 
>>> *not proposing this, haven't thought carefully about whether there are edge 
>>> cases I'm missing here, but I think the analogy holds
>> 
>> I alluded to this kind of thing in the earlier threads.  It would be very 
>> cool to see this explored in the future.
>> 
>> I really like the latest draft and am eagerly anticipating Smart KeyPaths 
>> being implemented.  Thank you for listening to feedback from the community!
>> 
>> One possible future direction I have been wondering about is whether it 
>> might be interesting to expose an anonymous type for each distinct key path 
>> which would have static members for getting (and setting if mutable) the 
>> value.  The types would inherit from the most specific matching key path 
>> type included in this proposal.  This would allow us pass key paths 
>> statically using the type system and therefore not requiring any runtime 
>> overhead.  
>> 
>> I have experimented with this approach in some of my own code and it looks 
>> like it would be a very promising approach aside from the boilerplate 
>> required to write these types manually.  I have abandoned this approach for 
>> now because of the boilerplate and because the syntactic sugar of the key 
>> path shorthand in this proposal is too attractive to pass up.  I would love 
>> to explore it again in the future if key paths were to support this approach.
> 
> Our generics system does not require generic code to be de-genericized 
> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order 
> to be run.  The generic code for applying a value of an unknown key-path type 
> would look exactly like the non-generic code for applying a dynamic key-path 
> type.  To get a runtime benefit, the compiler would have to de-genericize all 
> the code between the function that formed the concrete key path and the 
> function that applied it.  If the compiler can do that, it can also 
> specialize that code for a known key path argument, the same way that it can 
> specialize a function for a known function argument.  So there's no point.

Thanks for the reply John.  There may not be any additional optimization 
opportunities in terms of code generation when using the key path but wouldn’t 
it save on storage and reference counting related to key path value?

As a secondary question, wouldn’t this be similar to the difference between 
generics and existentials?  In theory the same optimizations could be applied 
but in practice they are not always right now.  Is the plan to eventually put 
existentials on equal footing in terms of optimization?

> 
> John.
> 
>> 
>> Matthew
>> 
>>> 
 On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution 
 > wrote:
 
 I too find the backslash odd, as it’s usually of course used to escape 
 something.
 
 What about three periods?
 
 let firstFriendsNameKeyPath = Person...friends[0].name
 print(luke[keyPath: ...friends[0].name])
 
 
 I also find wanting to use the same syntax for unapplied methods strange, 
 as they would product two totally different things: one a key path value, 
 the other a function.
 
 Patrick
 On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution 
 > wrote:
> On Apr 5, 2017, at 4:55 PM, Colin Barrett  > wrote:
> 
> Is the choice of backslash up for review? I think another operator, 
 
 We talked through basically everything on the keyboard, and there really 
 aren’t other options that don’t stomp on existing behavior.
 
> perhaps backtick (`), would work better. 
 
 Backtick (`) is already taken for escaping identifiers, e.g., 
 
var `func` = { /* some code */ }
 
- Doug
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 

Re: [swift-evolution] Type-based ‘private’ access within a file

[Jordan Rose via swift-evolution]

Hi, -evolution. I’ve said this before, but I think this new proposal is a 
terrible idea. It privileges types in a way that is damaging to the language.

[There isn't really anything new in my discussion below; everyone on-thread is 
smart enough to have brought up these points already. But I wanted to go on 
record about it, at least.]

The claimed problem with the current version of 'private' (let's call it 
"scoped-private") is that it encourages developers to make monolithic type 
declarations instead of using extensions. With the proposed new interpretation 
(let's call it "extension-file-private"), there's a similar problem: developers 
are encouraged to put everything in the original type even when it may be more 
appropriate to

1. Extend another type (e.g. converting initializers)
2. Use a helper type (a nested type always inherits the generic parameters of 
its enclosing type)
3. Break a single protocol or class out into a hierarchy (subtyping should be 
used sparingly but not never)

Of course, one can always add an extension to access the extension-file-private 
members from outside the type, but that just underscores how little expressive 
power this level would actually have. These are cases where 'fileprivate' is 
the correct tool for the job.

I liked the original three levels of access (not a surprise to anyone, since I 
was a primary designer), and one reason for that is that the access levels are 
completely indepedent of the declarations you're writing. You can organize your 
code in whatever way makes the most sense, and the access levels will then help 
you enforce that organization. I do think SE-0025 should not have been 
accepted, that it does not add enough benefit given the increase to complexity, 
but even scoped-private can be used as an organizational feature that prevents 
you from making mistakes, and it still offers a simple answer to where a 
declaration can be used.

The proposed extension-file-private exposes a declaration to an arbitrary 
subset of the file it's in, because being within an extension of a type or not 
is arbitrary with regards to code organization. Extensions are used 
organizationally, but there's now no way to distinguish whether the private 
members of this extension are related to the private members of that extension, 
or whether they were supposed to be independent.

Everyone is acting like "fileprivate" is a problem. While we may not like the 
name, it's still the right tool for the job. What else do you have in the file 
that you're trying to protect?

Let's not add a mishmash of a feature just because it's "practical" for some 
uses.

Thanks for hearing me out,
Jordan

P.S. I have a lot to say on the idea of "submodules", and the dozen different 
things people want from them. I'll try to write that up later, so that people 
can refer to it if/when we ever get around to discussing such features. But 
it's not relevant right now.

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 10:28 AM, Ricardo Parada  wrote:
> 
> Do you think in the future it might be possible to convert to strings?  
> 
> For example, I am imagining a CoreData-like framework on the server (where 
> there is no Objective-C), where I would like to get the type of the root 
> object and keys forming the path.  That way I can go to an object model, get 
> the corresponding entity, and traversed relationships, and destination 
> attribute.  All that information (table name, table joins for the 
> relationships traversed, column names, etc.) would then be used to construct 
> the SQL.

Key-paths could be extended to allow introspection of the components along the 
path, in which case you would be able to map between key paths into your 
specific data model and the tables/columns in your database. This is not the 

- Doug

> 
> 
> 
>> On Apr 6, 2017, at 12:37 PM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Apr 6, 2017, at 9:31 AM, Sean Heber >> > wrote:
>>> 
>>> 
 On Apr 6, 2017, at 11:19 AM, Douglas Gregor > wrote:
 
> 
> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
> > wrote:
> 
> I agree, there's an analogy between strings and key paths, and in that 
> regards the single quote would make sense.  I would not complain.  
 
 The only analogy between strings and key-paths is that the existing Cocoa 
 APIs for key-paths use strings. That’s not an analogy to hang language 
 syntax on, because it’s relevance will fade quickly. 
>>> 
>>> Why would it fade quickly? Do we expect the concept of keypaths to go away 
>>> over time? If so, why are we even designing a syntax for keypaths?
>> 
>> The link between key-paths and strings will go away over time. The *only* 
>> reason anyone associates strings with keypaths is because Cocoa’s current 
>> key-paths are string-based. This proposal makes any string representation of 
>> key-paths an implementation detail that could be used for interoperability 
>> with Cocoa’s current system. There is no reason for a type-unsafe string 
>> representation to ever be in the user model.
>> 
>> 
 The core team discussed single quotes, and decided that we want to save 
 them for something in the string/character realm.
>>> 
>>> Are they to be saved for something specific or is this just because a lot 
>>> of languages use single quotes for character literals? Why is this 
>>> association any more sacred than an association with Cocoa string keypaths?
>> 
>> 
>> Lots of languages use single quotes for character literals; we may want to 
>> bring them back for it.
>> 
>>  - Doug
> 

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

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[John McCall via swift-evolution]

> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution 
>  wrote:
>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution 
>> > wrote:
>> 
>> The rationale for using the same syntax is that a KeyPath is an unapplied 
>> property/subscript access. Even the multi-segment part of it isn't 
>> necessarily dissimilar: I don't think it would be unreasonable to imagine 
>> that \Foo.someMethod.someOtherMethod could work*, that'd just be function 
>> composition after all.
>> 
>> KeyPath : Properties/Subscripts :: Functions with a self argument : Methods
>> 
>>  David
>> 
>> *not proposing this, haven't thought carefully about whether there are edge 
>> cases I'm missing here, but I think the analogy holds
> 
> I alluded to this kind of thing in the earlier threads.  It would be very 
> cool to see this explored in the future.
> 
> I really like the latest draft and am eagerly anticipating Smart KeyPaths 
> being implemented.  Thank you for listening to feedback from the community!
> 
> One possible future direction I have been wondering about is whether it might 
> be interesting to expose an anonymous type for each distinct key path which 
> would have static members for getting (and setting if mutable) the value.  
> The types would inherit from the most specific matching key path type 
> included in this proposal.  This would allow us pass key paths statically 
> using the type system and therefore not requiring any runtime overhead.  
> 
> I have experimented with this approach in some of my own code and it looks 
> like it would be a very promising approach aside from the boilerplate 
> required to write these types manually.  I have abandoned this approach for 
> now because of the boilerplate and because the syntactic sugar of the key 
> path shorthand in this proposal is too attractive to pass up.  I would love 
> to explore it again in the future if key paths were to support this approach.

Our generics system does not require generic code to be de-genericized 
("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order to 
be run.  The generic code for applying a value of an unknown key-path type 
would look exactly like the non-generic code for applying a dynamic key-path 
type.  To get a runtime benefit, the compiler would have to de-genericize all 
the code between the function that formed the concrete key path and the 
function that applied it.  If the compiler can do that, it can also specialize 
that code for a known key path argument, the same way that it can specialize a 
function for a known function argument.  So there's no point.

John.

> 
> Matthew
> 
>> 
>>> On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution 
>>> > wrote:
>>> 
>>> I too find the backslash odd, as it’s usually of course used to escape 
>>> something.
>>> 
>>> What about three periods?
>>> 
>>> let firstFriendsNameKeyPath = Person...friends[0].name
>>> print(luke[keyPath: ...friends[0].name])
>>> 
>>> 
>>> I also find wanting to use the same syntax for unapplied methods strange, 
>>> as they would product two totally different things: one a key path value, 
>>> the other a function.
>>> 
>>> Patrick
>>> On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution 
>>> > wrote:
 On Apr 5, 2017, at 4:55 PM, Colin Barrett > wrote:
 
 Is the choice of backslash up for review? I think another operator, 
>>> 
>>> We talked through basically everything on the keyboard, and there really 
>>> aren’t other options that don’t stomp on existing behavior.
>>> 
 perhaps backtick (`), would work better. 
>>> 
>>> Backtick (`) is already taken for escaping identifiers, e.g., 
>>> 
>>> var `func` = { /* some code */ }
>>> 
>>> - Doug
>>> 
>>> 
>>> ___
>>> 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 
> 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

Yes but that is a bit different.  Spaces can be used for clarity or breaking up 
a chain into multiple lines maybe.  But, the space is not really part of the 
key path.  I would expect the key path to be typed in without spaces when using 
the special syntax.


> On Apr 6, 2017, at 12:45 PM, Ben Rimmington  wrote:
> 
> 
>> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution 
>> > wrote:
>> 
>> Another thought on the use of single quotes (an possibly the proposed escape 
>> character).  Do you think the closing single quote could be made optional 
>> since key paths cannot have spaces? Or would that be confusing for beginners?
> 
> Key paths can (probably) have spaces:
> 
>   Welcome to Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.48).
> 1> Double.nan.isNaN
>   $R0: Bool = true
> 2> Double . nan . isNaN
>   $R1: Bool = true
> 3> Double .nan .isNaN
>   $R2: Bool = true
> 4> Double. nan. isNaN
>   error: extraneous whitespace after '.' is not permitted
>   Double. nan. isNaN
> ^~
> 
>> For example, these two would be equivalent:
>> 
>>let isPuppyPredicate = 'Pet.type == .dog && 'Pet.age < 12
>>let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
>> 
>> Or this:
>> 
>>let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
>>let isPuppyPredicate = \Pet.type\ == .dog && \Pet.age\ < 12
>> 
>> You would use the closing character normally when wanting to invoke a method 
>> on the key path object.
>> 
>> Any thoughts?
> 

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

Do you think in the future it might be possible to convert to strings?  

For example, I am imagining a CoreData-like framework on the server (where 
there is no Objective-C), where I would like to get the type of the root object 
and keys forming the path.  That way I can go to an object model, get the 
corresponding entity, and traversed relationships, and destination attribute.  
All that information (table name, table joins for the relationships traversed, 
column names, etc.) would then be used to construct the SQL.



> On Apr 6, 2017, at 12:37 PM, Douglas Gregor  wrote:
> 
>> 
>> On Apr 6, 2017, at 9:31 AM, Sean Heber  wrote:
>> 
>> 
>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor  wrote:
>>> 
 
 On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
  wrote:
 
 I agree, there's an analogy between strings and key paths, and in that 
 regards the single quote would make sense.  I would not complain.  
>>> 
>>> The only analogy between strings and key-paths is that the existing Cocoa 
>>> APIs for key-paths use strings. That’s not an analogy to hang language 
>>> syntax on, because it’s relevance will fade quickly. 
>> 
>> Why would it fade quickly? Do we expect the concept of keypaths to go away 
>> over time? If so, why are we even designing a syntax for keypaths?
> 
> The link between key-paths and strings will go away over time. The *only* 
> reason anyone associates strings with keypaths is because Cocoa’s current 
> key-paths are string-based. This proposal makes any string representation of 
> key-paths an implementation detail that could be used for interoperability 
> with Cocoa’s current system. There is no reason for a type-unsafe string 
> representation to ever be in the user model.
> 
> 
>>> The core team discussed single quotes, and decided that we want to save 
>>> them for something in the string/character realm.
>> 
>> Are they to be saved for something specific or is this just because a lot of 
>> languages use single quotes for character literals? Why is this association 
>> any more sacred than an association with Cocoa string keypaths?
> 
> 
> Lots of languages use single quotes for character literals; we may want to 
> bring them back for it.
> 
>   - Doug

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

[swift-evolution] Warning on name collisions with functions in protocol extensions

[Brian King via swift-evolution]

Has there been any conversation around generating a warning if a type
implements a function that is also implemented in an extension of a
conforming protocol? This is a frequent source of confusion for new swift
developers, and I think the reaction to this behavior is more severe than
it needs to be because the compiler does not help identify or explain the
nuance.

My gut feeling is that intended (or required) function collisions are very
rare. I think forcing the user to rename the colliding function would work
most of the time. The language could have an attribute like
`@iMeantToCollideFunctions` to disable the warning when it was intended,
although no good name for this attribute comes to mind. It feels like there
needs to be some way to disable the warning when the collision is accepted,
even if it is a rare use case. Colliding functions could also be not
supported, just like conforming to 2 protocols with colliding default
implementations.

Anyway, I'm not sure if this has been discussed and dismissed already. I've
been having fun exploring compiler warnings to help developers avoid
dispatch confusion, and was interested in what people thought.

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Kevin Nattinger via swift-evolution]

>> On Apr 5, 2017, at 6:54 PM, Nevin Brackett-Rozinsky via swift-evolution 
>> > wrote:
>> 
>> On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>  - fileprivate should really become much more rare, which makes it more 
>> meaningful and significant where it occurs.  This was the original idea and 
>> intent behind SE-0025.
>> 
>> I would like to understand the reasoning here. I just looked back at SE-0025 
>> and I see this same assertion, but I cannot find the reasoning. Could you 
>> explain it to me please?

The idea of a private member is that it’s only visible within the class that 
declares it. In languages where the class is traditionally declared all at 
once, that’s straightforward enough; however, the tradition of implementing 
swift classes as a series of extensions (currently) forces opening much more 
than should be to any other classes within the file.  If class B needs access 
to one private within class A, it also gets access to every single variable 
used by an extension to A, and every single function used by an extension 
outside the one it’s declared in. That’s way more visibility into the class 
than it should have.

>> 
>> Certainly I would love to make the *spelling* of “fileprivate” be entirely 
>> nonexistent. But all the lines of logic I have come up with lead inexorably 
>> to the conclusion that the *semantics* of “fileprivate” should be the 
>> common, de facto, access level that people reach for when they need 
>> encapsulation.
>> 
>> 1. Someone makes a file with a single type in it, and marks the 
>> implementation details “private”. At this point, it does not matter matter 
>> which meaning “private” has, they all work the same so far.
>> 
>> 2. The developer adds a free function to the file. Or an extension of 
>> another type. Or another type entirely. And they put it in the same file 
>> because it needs to work with the implementation details of the existing 
>> type.

IMO having a free function access the internals of an object is a huge code 
smell. It should almost always be a function on the object or the class. And 
I’d be highly skeptical of any architecture that requires one class to access 
another class’s privates directly.  In general, I’m fairly strongly opposed to 
having multiple externally accessible classes in the same file (probably 
influenced by having used Java through most of my education).

>> 
>> Now the difference between possible meanings of “private” matters. And if it 
>> is anything short of “fileprivate”, then the developer has to go back and 
>> change access levels. Things no longer “just work”.

Well, yes, that’s what I’d expect and want, and that’s the whole point of 
access levels. If I have a private member and want to use it in another class, 
I should have to make a conscious decision about whether to open up that 
member, add an externally visible one, or just do it a different way entirely. 
(One might argue based on that point that the fix-it to widen the access level 
is actually harmful.) I’m not sure what your point is here, but I think forcing 
the dev to stop and think about whether the access needs to be loosened is a 
*good* thing.

>> 
>> The alternative scenario is that one adds something to the file which 
>> doesn’t need privileged access to what’s already there. In which case the 
>> questions are, “Why put it in the same file at all?” and “If there is a good 
>> reason to put it in the same file, is there any *harm* in it being able to 
>> see private members?”

Again I’m not seeing your point. Yes, you should think twice about why it’s in 
the same file. Yes, there is harm because it can now see fileprivate members 
that it shouldn’t.

>> 
>> Most developers most of the time should not have to think about 
>> sub-file-level granularity. If things are in the same file it is because 
>> they need to work together closely. We should be able to mark members 
>> “private” and work with them across the file. This dramatically reduces the 
>> cognitive burden, and the amount of time spent fiddling with access levels.

Are you arguing for reverting to the Swift 2 definition of private = modern 
fileprivate? 

I’d argue exposing privates to everything in a file actually *increases* 
cognitive load because now I have to keep track of which classes are declared 
in the same file. If private has a sane meaning (initial declaration + 
“primary” extensions, the level under consideration here) only the class I know 
I’m working in has access. Much simpler and context-free.

>> 
>> With any meaning of “private” less than “fileprivate”, developers end up 
>> marking things “private”, then letting the IDE change it to “fileprivate” 
>> when the compiler complains. This tells me that people actually want the 
>> semantics of “fileprivate”, and they want it to be spelled “private”.

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

[Rien via swift-evolution]

Having just finished a client/server framework that builds on openSSL I 
sympathise with this proposal.

However, I wrote a few blogposts about my experiences with openSSL. And those 
leads me to believe that there is not much interest in secure networking. The 
number of hits on those posts are quite low (anaemic even) when compared to 
-for example- posts on socket programming.

While the sketch you made below does not sound too bad, I am afraid that the 
API will become complex so fast, that it will not be much easier to use than 
openSSL/LibreSSL etc. But don’t let that stop you ;-)

Regards,
Rien

PS: https://github.com/Balancingrock/SecureSockets


Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 06 Apr 2017, at 18:16, Gelareh Taban via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I’d like to pitch some of the ideas that have been discussed in the server 
> working group around security. 
> 
> To get more information on the server API group and its goals, see 
> https://swift.org/server-apis/. (TL;DR version is to come up with a set of 
> foundational APIs that work cross-platform, on all platforms supported by 
> Swift, including Linux.) 
> 
> For security, we have divided the scope into SSL/TLS support and crypto 
> support. Our first goal and the subject of this pitch is TLS. This current 
> pitch is the result of various discussions that have taken place over the 
> past several months over the server working group mailing list and several 
> projects by groups such as Vapor, IBM, Zewo, etc. 
> 
> Our plan is to start with the main ideas presented here and work on a Swift 
> library that we prototype and iterate on before finalizing on a specific 
> interface. Hopefully the ideas in this pitch are non-controversial, aside 
> from the naming of the method and protocols (which is widely accepted as a 
> `hard` problem).
> 
> # Problem
> 
> Since there is currently no standard Swift SSL/TLS library that is compatible 
> on both Apple and Linux, Swift projects use their TLS library of choice (such 
> as OpenSSL, LibreSSL, Security framework, etc). This results in:
> - fragmentation of the space as well as incompatibility of project 
> dependencies if more than one security package is needed by different modules 
> (a project cannot have both OpenSSL and LibreSSL in its dependency graph)
> - insecurity (using an unpatched or deprecated library such as OpenSSL on 
> macOS)
> - unmaintainablity (using non-standard or non-native libraries)
> - more complex code (using different APIs or code paths for each platform).
> 
> So we want to propose a standard set of protocols that define the behavior of 
> the TLS service and how the application and the server and networking layers 
> beneath it interact with the TLS service. What complicates this pitch is that 
> the Swift in server space is new and none of the interfaces have yet been 
> defined, so this is really a work in iteration.
> 
> # Design goals
> 
> We came up with the following design goals for a solution:
> 
> - Provide a consistent and unified Swift interface so that the developer can 
> write simple, cross-platform applications;
> - Don't implement new crypto functionality and instead use existing functions 
> in underlying libraries;
> - Plug-n-play architecture which allows the developer to decide on underlying 
> security library of choice, e.g., OpenSSL vs LibreSSL;
> - Library should be agnostic of the transport mechanism (e.g., socket, etc), 
> whilst allowing for both blocking and non-blocking connections;
> - Developers should be able to use the same TLS library for both client and 
> server applications.
> 
> 
> # Proposal
> 
> The proposed solution basically defines a number of protocols for each 
> interface:
> - Transport management
> - TLS management
> 
> A basic diagram that shows the relationship between the proposed protocols is 
> shown below:
> 
> (See attached file: TLSServiceArchitecture.png)
> 
> ![alt 
> text](https://raw.githubusercontent.com/gtaban/blogs/master/TLSServiceArchitecture.png
>  "Architecture of TLSService modules")
> 
> 
> The transport management protocol essentially would be a combination of a 
> connection object (e.g., a socket pointer, a file descriptor, etc) and a 
> connection type.
> 
> This is the connection object that gets passed to the implementation of the 
> TLS service protocol, which also handles the read and write callbacks to the 
> connection object.
> 
> The TLS service protocol would define a sets of methods that deal with TLS 
> setup (certificates, server/client, etc), and TLS events (such as receiving 
> data, encrypting and writing to connection object or reading from a 
> connection object, decrypting and returning the data).
> These methods are implemented by the TLS service which in turn uses its 
> choice of underlying 

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

[Nate Cook via swift-evolution]

> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>>  • What is your evaluation of the proposal?
> 
> (As a meta issue, I'm not sure I like the grab-bag review style; I'm finding 
> this proposal a little bit difficult to navigate.)
> 
> Sequence-based initializer and merging initializer
> 
> Good idea, but I think these two are redundant with each other, and I don't 
> think "merging" is an accurate way to describe what the second one does. 
> (`merging` would suggest to me that it was combining several dictionaries or 
> lists, not combining conflicting elements.) I'd suggest a single initializer 
> along the lines of:
> 
>   init(_ keysAndValues: S, correctingConflictsBy 
> resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate 
> values \($0) and \($1)") }) rethrows
>   where S.Iterator.Element == (key: Key, value: Value)

Thanks for all your feedback, Brent! One note on this item in particular—if you 
specify a default argument for a throws/rethrows closure, you have to use "try" 
at the call site even if the default closure argument doesn't throw. Modules 
currently don't promise that default closure arguments don't throw, and a 
default argument could change from non-throwing to throwing in a later version 
of a library.

There's a bug tracking the issue here: https://bugs.swift.org/browse/SR-2979

> Merging methods
> 
> Good idea, but I'm not a fan of the `mergingValues:` label. I would suggest 
> the same `correctingConflictsBy resolveConflict:` label I suggested for the 
> previous method—possibly including the default value. I also think 
> `merge(_:correctingConflictsBy:)`'s first parameter should be labeled `with`, 
> just as the `merged` variant is.
> 
> I wonder if we might also want a method that copies the Dictionary, but with 
> a single key added/removed/changed:
> 
>   func withValue(_ value: Value?, forKey key: Key) -> [Key: Value]
> 
> Key-based subscript with default value
> 
> I like the functionality, but not way this proposal does it. I don't like 
> having the default value be a labeled parameter to the subscript, because it 
> isn't used to locate the value. However, I can't come up with a better syntax 
> without adding language features. What I'd like to do is make it possible to 
> assign through `??`:
> 
>   frequencies[c] ?? 0 += 1
> 
> But that would require either that we support `inout` functions, or that `??` 
> become magic syntax instead of a standard library feature. The former is not 
> coming in Swift 4 and the latter is less than ideal.
> 
> Still, if we would rather have that syntax and we think we'll soon have the 
> language improvements needed to pull it off, I'd suggest rejecting this 
> portion of the proposal.
> 
> Dictionary-specific map and filter
> 
> I am +114 on this. I say that because I have received 114 upvotes on my Stack 
> Overflow answer explaining how to write a `Dictionary.map` method: 
>   
> >
> 
> I agree with the decision not to pass keys to the closures in these methods; 
> that keeps them simple and focused, and ensures they stay parallel with 
> ordinary `map` and `filter`. I also agree with the decision to not build in a 
> form of `map` which allows key remapping; you can always do that with the 
> sequence-based initializer, which would let you add conflict-handling logic 
> more elegantly than a key-value `map` could.
> 
> Visible dictionary capacity
> 
> I doubt I'll ever use the `capacity` property, but I'm not opposed to it. 
> Adding a `reserveCapacity(_:)` method is a good idea.
> 
> A grouped(by:) method for sequences
> 
> Yes, please.
> 
> Apply relevant changes to Set
> 
> These make sense. (I considered suggesting the `filter` method be called 
> `intersection(where:)`, but on second thought, I don't think that conveys the 
> actual use cases for the method very well.)
> 
> I wonder if we might want to conform `Dictionary` to `SetAlgebra`. They have 
> compatible semantics, and I've occasionally wanted to use them in the same 
> places. On the other hand, some of the methods might form attractive 
> nuisances; perhaps I should just write a SetAlgebra-conforming view when I 
> want to do that.
> 
> General notes
> 
> If SE-0161 is accepted, we may want to support key path variants of some of 
> these APIs (like `grouped(by:)`, `map(_:)`, and `filter(_:)`). On the other 
> hand, we may want to defer that so we can consider that issue holistically, 
> including with existing Collection APIs.
> 
>>  • Is the problem being addressed 

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ben Rimmington via swift-evolution]

> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution 
>  wrote:
> 
> Another thought on the use of single quotes (an possibly the proposed escape 
> character).  Do you think the closing single quote could be made optional 
> since key paths cannot have spaces? Or would that be confusing for beginners?

Key paths can (probably) have spaces:

Welcome to Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.48).
  1> Double.nan.isNaN
$R0: Bool = true
  2> Double . nan . isNaN
$R1: Bool = true
  3> Double .nan .isNaN
$R2: Bool = true
  4> Double. nan. isNaN
error: extraneous whitespace after '.' is not permitted
Double. nan. isNaN
  ^~

> For example, these two would be equivalent:
> 
>let isPuppyPredicate = 'Pet.type == .dog && 'Pet.age < 12
>let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
> 
> Or this:
> 
>let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
>let isPuppyPredicate = \Pet.type\ == .dog && \Pet.age\ < 12
> 
> You would use the closing character normally when wanting to invoke a method 
> on the key path object.
> 
> Any thoughts?

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Tony Allevato via swift-evolution]

On Thu, Apr 6, 2017 at 9:31 AM Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 6, 2017, at 11:19 AM, Douglas Gregor  wrote:
> >
> >>
> >> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I agree, there's an analogy between strings and key paths, and in that
> regards the single quote would make sense.  I would not complain.
> >
> > The only analogy between strings and key-paths is that the existing
> Cocoa APIs for key-paths use strings. That’s not an analogy to hang
> language syntax on, because it’s relevance will fade quickly.
>
> Why would it fade quickly? Do we expect the concept of keypaths to go away
> over time? If so, why are we even designing a syntax for keypaths?
>

I think the naming of this proposal as "keypaths" has caused some confusion
in this regard. Try to consider them without the Objective-C history and
look at Swift as a language in its own right: does it make sense for a
chain of strongly-typed unbound property references—AND unbound method
references, because they will use this syntax as well—to be represented as
something akin to a string literal? IMO, the answer to that is no.

Nobody is suggesting that the concept of keypaths will go away—the proposal
is evidence of that and in fact it shows that they want to improve them
beyond the string-based versions that were required by Objective-C because
of its dynamism and string-based-selector syntax.

It would be a mistake to tie down Swift's superior implementation based on
tortured analogies to Objective-C.


>
>
> > The core team discussed single quotes, and decided that we want to save
> them for something in the string/character realm.
>
> Are they to be saved for something specific or is this just because a lot
> of languages use single quotes for character literals? Why is this
> association any more sacred than an association with Cocoa string keypaths?
>
> l8r
> Sean
>
> ___
> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Sean Heber via swift-evolution]

> On Apr 6, 2017, at 11:19 AM, Douglas Gregor  wrote:
> 
>> 
>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> I agree, there's an analogy between strings and key paths, and in that 
>> regards the single quote would make sense.  I would not complain.  
> 
> The only analogy between strings and key-paths is that the existing Cocoa 
> APIs for key-paths use strings. That’s not an analogy to hang language syntax 
> on, because it’s relevance will fade quickly. 

Why would it fade quickly? Do we expect the concept of keypaths to go away over 
time? If so, why are we even designing a syntax for keypaths?


> The core team discussed single quotes, and decided that we want to save them 
> for something in the string/character realm.

Are they to be saved for something specific or is this just because a lot of 
languages use single quotes for character literals? Why is this association any 
more sacred than an association with Cocoa string keypaths?

l8r
Sean

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