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

[David Beck via swift-evolution]

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

I’m a very big fan of solving this problem, and this seems like a pretty 
flexible solution for the future.

I like the “::” solution, but could live with the proposed syntax. Also, that 
seems like an aspect that could be changed, either additively, or at the very 
least without breaking ABI stability.

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

YES! While KVO and KVC are big use cases for key paths, other use cases exist 
that make sense for non-objc code to use, especially db related models.

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

For the most part. Like many have said, the slash is a little out of place, but 
hen again, that’s why it was chosen, so that it doesn’t conflict with other 
operators.

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

Most languages that I’ve used this kind of feature with (including ObjC) just 
use stringly typed constructs, which have obvious issues.

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

a quick reading

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


David Beck
dav...@acst.com
http://www.acstechnologies.com

___
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

[Karl Wagner via swift-evolution]

> On 9 Apr 2017, at 19:36, Tino Heth via swift-evolution 
>  wrote:
> 
> -1:
> Although prefix "\" is imho the nicest variation that has been officially 
> suggested for this feature (I still like infix ":" better; maybe I've been 
> using classic MacOS to long), there is no general agreement, and many people 
> that voted "+1" did so despite preferring a different syntax, just because 
> they want to have the feature asap.
> 
> But haste is a bad counsellor, and if we learned anything from the disaster 
> of "new private", we shouldn't rush and constitute how an obviously important 
> (or at least popular) feature should look like without taking into account 
> the big picture:
> KeyPaths are at least entwined with method references and reflection, so 
> until we have a concrete idea of those ties, no narrow proposal should be 
> implemented*.
> 
> - Tino
> 
> * preliminary acceptance with delayed implementation would be fine for me — I 
> just don't want to paint ourselves into a corner...
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Or the other way around - if its implementable right now, we should do it and 
gather feedback on the syntax in real usage. I think we’re all agreed on the 
functionality.

Personally, I’d like to see these smart KeyPaths become more of a first-class 
language feature. We should define a new family of operators to use with them, 
instead of named methods. The “::” member reference operator (on a type, 
returning a keypath, or on a keypath, returning a sub-keypath) could be one.

Subscripting: replace with arrow (indirect access) operator. Parallels the dot 
operator for direct access. “Indirect” here means the keypath, since it may be 
invalid for this object and return nil (depending on which keypath you provide).

let name = luke->firstFriendNameKeyPath // “Han Solo"
let name = luke->friends[0]::name // Equivalent to luke.friends[0].name

Appending: replace with backslash operator.

let personName = Person::name
let nameToFind = luke->personName // “Luke Skywalker”
for p in people {
   if p->friends[0]\personName == nameToFind { return p }
}

If you are directly entering a keypath, we could infer the type for the :: 
operator, so you could just directly type members in. That’s fine - if you’re 
accessing a known member on a known type, even by keypath, “->" will get 
optimised in to a direct access anyway.

let name = AnyKeyPath(Person::name)
for p in people {
if let n = p->friends[0]\name, n == nameToFind { return p }
}

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

[Tino Heth via swift-evolution]

-1:
Although prefix "\" is imho the nicest variation that has been officially 
suggested for this feature (I still like infix ":" better; maybe I've been 
using classic MacOS to long), there is no general agreement, and many people 
that voted "+1" did so despite preferring a different syntax, just because they 
want to have the feature asap.

But haste is a bad counsellor, and if we learned anything from the disaster of 
"new private", we shouldn't rush and constitute how an obviously important (or 
at least popular) feature should look like without taking into account the big 
picture:
KeyPaths are at least entwined with method references and reflection, so until 
we have a concrete idea of those ties, no narrow proposal should be 
implemented*.

- Tino

* preliminary acceptance with delayed implementation would be fine for me — I 
just don't want to paint ourselves into a corner...
___
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

[Thorsten Seitz via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>  
> 
> What is your evaluation of the proposal?
+1 in general 

BUT I absolutely dislike having to escape a key path with `\` which is 
absolutely counterintuitive IMHO.
Like Brent already wrote, the `\` has to encompass the full expression to avoid 
ambiguities; this is so foreign to how `\` usually works, i.e. only on the 
following character, that it further makes the syntax counterintuitive and ugly.

I would have preferred one of these

1.
@{Type.property[.property]*}
  // no ambiguities due to braces
  let kp = @{Person.bestFriend?.name}
  luke[keyPath: @{.bestFriend?.name}]

2.
@Type.property[.property]*
  // @ applies to whole expression to make unambiguous (just like Brent 
suggested for `\`)
  let kp = @Person.bestFriend?.name
  luke[keyPath: @.bestFriend?.name]

3.
Type@property[.property]*
  // @ applies to whole expression to make unambiguous (just like Brent 
suggested for `\`)
  let kp = Person@bestFriend?.name  
  luke[keyPath: @bestFriend?.name]

4.
Type@property[@property]*
  // no ambiguities due to different separators; might be used for method 
references as well
  let kp = Person@bestFriend?@name
  luke[keyPath: @bestFriend?@name]

5.
#keyPath(Type.property[.property]*)
  // no ambiguities due to parenthesis
  let kp = #keyPath(Person.bestFriend?.name)
  luke[keyPath: #keyPath(.bestFriend?.name)]


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

Yes, definitely!

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


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

Followed much of the discussion, read the proposal.

-Thorsten

___
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

[Karl Wagner via swift-evolution]

> On 7 Apr 2017, at 03:28, Rick Mann via swift-evolution 
>  wrote:
> 
> I tend to dislike the backslash as well, but can't suggest a good alternative.
> 

The quirky thing I like about the backslash is that it almost looks like a URL. 
It might be nice to concatenate keypaths in that way (replacing the append 
methods):

let firstFriend = \Person.friends.first!
let name = \Person.name
let firstFriendNameLength = luke[keyPath: firstFriend\name\.characters.count] 
// 8 (“Han Solo”)

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


That could be ambiguous if you had some kind of collection which was indexed by 
keypaths. For example, you might have a dictionary of [KeyPath : String] for 
some kind of mapping.

I agree that the subscript is ugly - it makes key-path access feel second class 
to direct access (via the dot operator). Perhaps it could be replaced by an 
instance method (on KeyPath) or get its own operator.

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

[Haravikk via swift-evolution]

> On 9 Apr 2017, at 05:12, Tony Allevato  wrote:
> 
> Agreed—I think the parentheses have to go on the outside for this to work. In 
> this sense, `\Person.mother.age` is an expression that returns a keypath 
> type, with the idea that the parser is greedy and tries to take as many 
> dotted names that follow. The parentheses halt that if needed, but the 
> backslash needs to be bound to the type name for the part inside the 
> parentheses to be interpreted as a keypath.
> 
> `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then 
> compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` 
> makes it clear that the keypath expression is being separated from whatever 
> might come after it.

I kind of like having it outside the brackets for the consistency with 
inserting variables etc. within strings; I've learned to think of that as a 
special type of escape from the "string" context, so it could make sense for 
key-paths in the same way.

I'm just thinking that since we're using a backlash it feels a lot like we're 
escaping from normal type access in order to define the key-path instead, and 
since \() is a form of escape used inside strings to encompass something larger 
it makes a kind of sense to me.

As Brent says though it shouldn't be a very common case so it doesn't really 
matter; I'd be fine with either style. I suppose using the backslash inside the 
brackets may be simpler to parse since it's using the parenthesis as normal?
___
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

[Brent Royal-Gordon via swift-evolution]

> On Apr 8, 2017, at 9:12 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then 
> compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` 
> makes it clear that the keypath expression is being separated from whatever 
> might come after it.


Backing this up: It's also worth remembering that this syntax is an edge case. 
The vast majority of key paths will not be ambiguous in a way that requires 
parentheses. Even if you think \(Foo.bar) would look better than (\Foo.bar), 
you should keep in mind that most of the time, you'll only need \Foo.bar, and 
the parenthesized syntax should be a natural extension of that. 

-- 
Brent Royal-Gordon
Sent from my iPhone

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

Agreed—I think the parentheses have to go on the outside for this to work.
In this sense, `\Person.mother.age` is an expression that returns a keypath
type, with the idea that the parser is greedy and tries to take as many
dotted names that follow. The parentheses halt that if needed, but the
backslash needs to be bound to the type name for the part inside the
parentheses to be interpreted as a keypath.

`\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then
compute the "keypath" of that, which doesn't make sense, whereas
`(\Foo.bar)` makes it clear that the keypath expression is being separated
from whatever might come after it.


On Sat, Apr 8, 2017 at 6:12 PM Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

At one point I was leaning towards a trailing backslash.  Now I prefer
parenthesis.

If parentheses are used should the escape character be outside the
parenthesis or inside?  For example:

let x = (\Person.mother.age).valueType
let y = (\Person.mother.age.valueType)

vs.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference.




On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:


On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

I love the idea of a leading and trailing backslash. It makes it much
easier to read, and handles the "but what if I want to access a property of
a KeyPath?" case really well.

For example, these two are clearly distinct:

  let x = \Person.mother.age\.valueType

  let y = \Person.mother.age.valueType\

I'm not sure why an 'age' object would have a 'valueType' property, but
this variant makes it easy to handle. Even in cases where no disambiguation
is required, having the trailing backslash makes it much easier to read as
I'm scanning through code.

-BJ


I think I'd prefer brackets for that case; in your first example that reads
to me like an escape of the period character, rather than "this is the end
of the key path". Brackets would make this consistent with escaping within
strings, like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an
escape from normal type/variable access. Put another way, normally when you
type Person. you're telling Swift "access this type and look for static
methods/properties etc.", whereas when you "escape" it you're telling Swift
to *not* to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the
use of brackets just looks cleaner than another backslash.
___
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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

At one point I was leaning towards a trailing backslash.  Now I prefer 
parenthesis.

If parentheses are used should the escape character be outside the parenthesis 
or inside?  For example:

let x = (\Person.mother.age).valueType
let y = (\Person.mother.age.valueType)

vs.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference. 




> On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> I love the idea of a leading and trailing backslash. It makes it much easier 
>> to read, and handles the "but what if I want to access a property of a 
>> KeyPath?" case really well.
>> 
>> For example, these two are clearly distinct:
>> 
>>   let x = \Person.mother.age\.valueType
>> 
>>   let y = \Person.mother.age.valueType\
>> 
>> I'm not sure why an 'age' object would have a 'valueType' property, but this 
>> variant makes it easy to handle. Even in cases where no disambiguation is 
>> required, having the trailing backslash makes it much easier to read as I'm 
>> scanning through code.
>> 
>> -BJ
> 
> I think I'd prefer brackets for that case; in your first example that reads 
> to me like an escape of the period character, rather than "this is the end of 
> the key path". Brackets would make this consistent with escaping within 
> strings, like so:
> 
>   let x = \(Person.mother.age).valueType
>   let y = \(Person.mother.age.valueType)
> 
> Which makes sense to me if you consider the backslash in this case being an 
> escape from normal type/variable access. Put another way, normally when you 
> type Person. you're telling Swift "access this type and look for static 
> methods/properties etc.", whereas when you "escape" it you're telling Swift 
> to not to do that, resulting in a key-path instead.
> 
> Maybe it's a stretch, it that makes sense logically to me, plus I think the 
> use of brackets just looks cleaner than another backslash.
> ___
> 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

[Haravikk via swift-evolution]

> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>  wrote:
> 
> I love the idea of a leading and trailing backslash. It makes it much easier 
> to read, and handles the "but what if I want to access a property of a 
> KeyPath?" case really well.
> 
> For example, these two are clearly distinct:
> 
>   let x = \Person.mother.age\.valueType
> 
>   let y = \Person.mother.age.valueType\
> 
> I'm not sure why an 'age' object would have a 'valueType' property, but this 
> variant makes it easy to handle. Even in cases where no disambiguation is 
> required, having the trailing backslash makes it much easier to read as I'm 
> scanning through code.
> 
> -BJ

I think I'd prefer brackets for that case; in your first example that reads to 
me like an escape of the period character, rather than "this is the end of the 
key path". Brackets would make this consistent with escaping within strings, 
like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an 
escape from normal type/variable access. Put another way, normally when you 
type Person. you're telling Swift "access this type and look for static 
methods/properties etc.", whereas when you "escape" it you're telling Swift to 
not to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the use 
of brackets just looks cleaner than another backslash.___
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

[BJ Homer via swift-evolution]

I love the idea of a leading and trailing backslash. It makes it much easier to 
read, and handles the "but what if I want to access a property of a KeyPath?" 
case really well.

For example, these two are clearly distinct:

  let x = \Person.mother.age\.valueType

  let y = \Person.mother.age.valueType\

I'm not sure why an 'age' object would have a 'valueType' property, but this 
variant makes it easy to handle. Even in cases where no disambiguation is 
required, having the trailing backslash makes it much easier to read as I'm 
scanning through code.

-BJ

>>> On Apr 5, 2017, at 9:13 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> It is also worth mentioning that, with the sigil, the `keyPath` label may not 
> be so necessary:
> 
>   print(luke[\.friends[0].name])
>   // or, if the suggestion above is accepted
>   print(luke[\.friends[0].name\])
> 
> ___
> 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

[Brent Royal-Gordon via swift-evolution]

> On Apr 6, 2017, at 11:01 AM, Brad Hilton via swift-evolution 
>  wrote:
> 
> How about Person.name.get / Person.name.set for getter/setter references.


We don't really want getter/setter references; we want one instance which 
represents the whole property and (if writable) can be used to modify it 
in-place if it's a value type.

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

[Joe Groff via swift-evolution]

> On Apr 7, 2017, at 12:01 PM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 2:50 PM, Joe Groff  wrote:
>>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>>> 
 On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>> 
>> 
>>> 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
> 
> Yeah, you can, but that's definitely an expressivity hit.
 
 True, but there are some benefits to requiring a subscript/property rather 
 than an arbitrary closure, particularly that it gives the operation a 
 stable identity and structure so the key path can still be equated/hashed 
 and (eventually) iterated through.
>>> 
>>> Right, I think if you add a method to the chain, the result definitely has 
>>> to be a function rather than a key path.  The idea is that you basically 
>>> decompose:
>>> 
>>> \Base.A.B.C
>>> 
>>> into
>>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>>> result(C)
>>> 
>>> except that if all of the components A, B, and C are just properties or 
>>> applied subscripts you can make it a KeyPath instead, which can 
>>> then contextually devolve into a function.
>> 
>> It seems to me that method references (non-mutating ones, at least) could 
>> still be treated as read-only key path components. There's not much more 
>> than syntax as a difference between a nonmutating method and get-only 
>> property or subscript. The method decl is still something we can ascribe 
>> identity to.
> 
> That's true.  My concern with ascribing identity to methods is that we have a 
> number of features around methods — overloading, default arguments, various 
> kinds of polymorphism — that make the exact choice of declaration somewhat 
> imprecise.  Should it be a different key path if we pick a protocol 
> requirement vs. a concrete method that satisfies it?  I suppose we have that 
> specific problem with properties and subscripts as well, though.

Yeah, the restrictions on overloading properties are effectively superficial, 
since protocol extensions and library evolution still give you means to end up 
with an overloaded property name. Subscripts are already arbitrarily 
overloadable.

-Joe
___
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 7, 2017, at 2:50 PM, Joe Groff  wrote:
>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
 On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
  wrote:
 
> 
> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> 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
 
 Yeah, you can, but that's definitely an expressivity hit.
>>> 
>>> True, but there are some benefits to requiring a subscript/property rather 
>>> than an arbitrary closure, particularly that it gives the operation a 
>>> stable identity and structure so the key path can still be equated/hashed 
>>> and (eventually) iterated through.
>> 
>> Right, I think if you add a method to the chain, the result definitely has 
>> to be a function rather than a key path.  The idea is that you basically 
>> decompose:
>> 
>> \Base.A.B.C
>> 
>> into
>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>> result(C)
>> 
>> except that if all of the components A, B, and C are just properties or 
>> applied subscripts you can make it a KeyPath instead, which can then 
>> contextually devolve into a function.
> 
> It seems to me that method references (non-mutating ones, at least) could 
> still be treated as read-only key path components. There's not much more than 
> syntax as a difference between a nonmutating method and get-only property or 
> subscript. The method decl is still something we can ascribe identity to.

That's true.  My concern with ascribing identity to methods is that we have a 
number of features around methods — overloading, default arguments, various 
kinds of polymorphism — that make the exact choice of declaration somewhat 
imprecise.  Should it be a different key path if we pick a protocol requirement 
vs. a concrete method that satisfies it?  I suppose we have that specific 
problem with properties and subscripts as well, though.

John.
___
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

[Matthew Johnson via swift-evolution]

> On Apr 7, 2017, at 1:50 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
>> 
>>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
 On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
  wrote:
 
> 
> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> 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
 
 Yeah, you can, but that's definitely an expressivity hit.
>>> 
>>> True, but there are some benefits to requiring a subscript/property rather 
>>> than an arbitrary closure, particularly that it gives the operation a 
>>> stable identity and structure so the key path can still be equated/hashed 
>>> and (eventually) iterated through.
>> 
>> Right, I think if you add a method to the chain, the result definitely has 
>> to be a function rather than a key path.  The idea is that you basically 
>> decompose:
>> 
>> \Base.A.B.C
>> 
>> into
>> ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
>> result(C)
>> 
>> except that if all of the components A, B, and C are just properties or 
>> applied subscripts you can make it a KeyPath instead, which can then 
>> contextually devolve into a function.
> 
> It seems to me that method references (non-mutating ones, at least) could 
> still be treated as read-only key path components. There's not much more than 
> syntax as a difference between a nonmutating method and get-only property or 
> subscript. The method decl is still something we can ascribe identity to.

I like where you guys are going with this!

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

[Joe Groff via swift-evolution]

> On Apr 7, 2017, at 11:48 AM, John McCall  wrote:
> 
>> On Apr 7, 2017, at 1:40 PM, Joe Groff  wrote:
>>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>>>  wrote:
>>> 
 
 On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
 
 
> 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
>>> 
>>> Yeah, you can, but that's definitely an expressivity hit.
>> 
>> True, but there are some benefits to requiring a subscript/property rather 
>> than an arbitrary closure, particularly that it gives the operation a stable 
>> identity and structure so the key path can still be equated/hashed and 
>> (eventually) iterated through.
> 
> Right, I think if you add a method to the chain, the result definitely has to 
> be a function rather than a key path.  The idea is that you basically 
> decompose:
> 
>  \Base.A.B.C
> 
> into
>  ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
> result(C)
> 
> except that if all of the components A, B, and C are just properties or 
> applied subscripts you can make it a KeyPath instead, which can then 
> contextually devolve into a function.

It seems to me that method references (non-mutating ones, at least) could still 
be treated as read-only key path components. There's not much more than syntax 
as a difference between a nonmutating method and get-only property or 
subscript. The method decl is still something we can ascribe identity to.

-Joe
___
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 7, 2017, at 1:40 PM, Joe Groff  wrote:
>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>>> 
>>> 
 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
>> 
>> Yeah, you can, but that's definitely an expressivity hit.
> 
> True, but there are some benefits to requiring a subscript/property rather 
> than an arbitrary closure, particularly that it gives the operation a stable 
> identity and structure so the key path can still be equated/hashed and 
> (eventually) iterated through.

Right, I think if you add a method to the chain, the result definitely has to 
be a function rather than a key path.  The idea is that you basically decompose:

  \Base.A.B.C

into
  ([inout]? Base, parameters(A)..., parameters(B)..., parameters(C)...) -> 
result(C)

except that if all of the components A, B, and C are just properties or applied 
subscripts you can make it a KeyPath instead, which can then 
contextually devolve into a function.

John.
___
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

[Joe Groff via swift-evolution]

> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
>> 
>> 
>>> 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
> 
> Yeah, you can, but that's definitely an expressivity hit.

True, but there are some benefits to requiring a subscript/property rather than 
an arbitrary closure, particularly that it gives the operation a stable 
identity and structure so the key path can still be equated/hashed and 
(eventually) iterated through.

-Joe
___
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 7, 2017, at 12:48 AM, Douglas Gregor  wrote:
> 
> 
>> 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

Yeah, you can, but that's definitely an expressivity hit.

John.


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

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

[Greg Titus via swift-evolution]

Mostly as a matter of historical interest:

The hard-coding of collection operators for KVC in Cocoa was more of a scope of 
documentation or API style decision than anything. The original implementation 
of KVC came from Enterprise Objects Framework (which then became WebObjects), 
and in both of those frameworks collection operators could be added just by 
implementing correctly named category methods on NSArray/NSSet. I.e. the 
implementation of valueForKeyPath: constructed a selector from the part 
following the ‘@‘ and checked to see if it existed.

- Greg

> On Apr 6, 2017, at 9:46 PM, John McCall via swift-evolution 
>  wrote:
> 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

___
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 21:46 , 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, 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.

Agreed. Whatever it is we come up with, I'd want it to be fully extensible, I 
just hope it's concise at the point of use.

Thanks!

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

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 #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] [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 #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 #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 #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] [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] [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] [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

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

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

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

- Doug


> 
> 
>> On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
 That's an interesting point. While `\` alone seems acceptable, I think 
 it's unfortunate that we'll have `(\...)` and `\(...)` both in the 
 language.
 Can we maybe consider instead:
 
let firstFriendsNameKeyPath = \Person.friends[0].name\
>>> 
>>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>>> 
>>> // Create a key path and use it
>>> let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>> luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>> 
>>> // or equivalently, with type inferred from context
>>> luke[keyPath: '.friends[0].name'] // "Han Solo"
>>> 
>>> // [SE-0042][SR-3550] Unapplied method references
>>> 'String.lowercased()'  // (String) -> String
>>> 'String.lowercased(with:)' // (String, Locale?) -> String
>>> 
>>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends 
>>> of the key path (or method reference).
>> 
>> For what it’s worth, I much rather prefer this approach and was going to 
>> suggest it today. In Objective-C, keypaths were just strings so by using a 
>> single tick, they still look *almost* like strings, but now they’re safe and 
>> checked by the compiler - magical.
>> 
>> 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

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

The escape character is already being used in String interpolation, i.e. 
\(foo). Also, escaping special characters in string literals, i.e. \t is tab, 
\n is a newline character, etc.  The single quote does not appear to be in use. 
 I believe it's not being used for string literals nor character literals:

ERROR at line 6, col 21: single-quoted string literal found, use '"'
let someCharacter = 'a'
^~~
"a"

Based on this, I don't think the use of single quote is a bad idea for Swift's 
smart key paths, IMHO.

But if the core team decides is reserved for something else, the escape 
character would be fine with me.  But I do think the single quote would be 
slightly superior to the escape character.





> On Apr 6, 2017, at 11:35 AM, James Berry via swift-evolution 
>  wrote:
> 
> +1 to this revised proposal.
> 
> I think the backslash is good. Even if it looks a little funny on first 
> blush, I think it’s the best choice. I don’t like other’s suggestion of 
> ‘keypath’, which I think is confusingly string-like: single quotes should be 
> saved for possible string expansions.
> 
> 
>> On Apr 5, 2017, at 4:56 PM, 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
>>  
>> 
>> 
> 
> 
>> What is your evaluation of the proposal?
> Strong +1. Let’s get this done.
> 
>> 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?
> This is great.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> In-depth.
> 
> ___
> 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

[James Berry via swift-evolution]

+1 to this revised proposal.

I think the backslash is good. Even if it looks a little funny on first blush, 
I think it’s the best choice. I don’t like other’s suggestion of ‘keypath’, 
which I think is confusingly string-like: single quotes should be saved for 
possible string expansions.


> On Apr 5, 2017, at 4:56 PM, 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
>  
> 


> What is your evaluation of the proposal?
Strong +1. Let’s get this done.

> 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?
This is great.

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

___
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

[Vladimir.S via swift-evolution]

On 06.04.2017 18:10, Ricardo Parada via swift-evolution wrote:

I did not mention single quotes because I was assuming those were reserved
for string literals.

But if they are available for something like this, it would make it obvious
where the key path begins and where it ends.  I went through my
hypothetical code samples, and I don't mind the \ escape character.  For
instance:

   let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
   let hasPuppiesPredicate = (\Family.pets).any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)

I don't mind having to use parenthesis sometimes when invoking a method on
key path for example.

With single quotes it would look like this:

   let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
   let hasPuppiesPredicate = 'Family.pets'.any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)



FWIW I find this much more clear and visually separated, my mind parses 
this code much faster then previous code block.
Although in this case we have some ambiguity (at first look) if 'Pet.type' 
is a string or escaped variable, but context will help very much when this 
feature is used IMO.


In any case, all suggested variants have some kind of ambiguity, so 
personally I think this is the best suggestion for now. Also, as was said, 
mentally it is close to keypath/selector string in ObjC.




And creating orderings for example:

   let orderings = [ 'Order.totalAmount'.desc,  'Order.address.zip'.asc ]




On Apr 6, 2017, at 9:55 AM, Ben Rimmington via swift-evolution
> wrote:

Re:



On 6 Apr 2017, at 04:13, Xiaodi Wu wrote:


On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote:


On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon wrote:

It's worth noting that, if you write `\Person.name.valueType`, this
syntax is ambiguous—it could mean "make a key path for the `valueType`
property on `name` property of `Person`", or it could mean "make a key
path for the `name` property of `Person`, then access the key path's
`valueType` property". We can solve this by always interpreting it as
the former and requiring parentheses for the latter—that is,
`(\Person.name).valueType`—but I thought it was worth calling out
explicitly.


Good point.

I'm thinking about the hypothetical code examples from previous emails:

  let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
  let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
  let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)


That's an interesting point. While `\` alone seems acceptable, I think
it's unfortunate that we'll have `(\...)` and `\(...)` both in the language.
Can we maybe consider instead:

let firstFriendsNameKeyPath = \Person.friends[0].name\


'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:

// Create a key path and use it
let firstFriendsNameKeyPath = 'Person.friends[0].name'
luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"

// or equivalently, with type inferred from context
luke[keyPath: '.friends[0].name'] // "Han Solo"

// [SE-0042][SR-3550] Unapplied method references
'String.lowercased()'  // (String) -> String
'String.lowercased(with:)' // (String, Locale?) -> String

Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends
of the key path (or method reference).

-- Ben

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




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


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

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?

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?


> On Apr 6, 2017, at 11: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.  
> 
> 
>> On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
 That's an interesting point. While `\` alone seems acceptable, I think 
 it's unfortunate that we'll have `(\...)` and `\(...)` both in the 
 language.
 Can we maybe consider instead:
 
let firstFriendsNameKeyPath = \Person.friends[0].name\
>>> 
>>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>>> 
>>> // Create a key path and use it
>>> let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>> luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>> 
>>> // or equivalently, with type inferred from context
>>> luke[keyPath: '.friends[0].name'] // "Han Solo"
>>> 
>>> // [SE-0042][SR-3550] Unapplied method references
>>> 'String.lowercased()'  // (String) -> String
>>> 'String.lowercased(with:)' // (String, Locale?) -> String
>>> 
>>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends 
>>> of the key path (or method reference).
>> 
>> For what it’s worth, I much rather prefer this approach and was going to 
>> suggest it today. In Objective-C, keypaths were just strings so by using a 
>> single tick, they still look *almost* like strings, but now they’re safe and 
>> checked by the compiler - magical.
>> 
>> 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

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

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.  


> On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution 
>  wrote:
> 
>>> That's an interesting point. While `\` alone seems acceptable, I think it's 
>>> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
>>> Can we maybe consider instead:
>>> 
>>> let firstFriendsNameKeyPath = \Person.friends[0].name\
>> 
>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>> 
>>  // Create a key path and use it
>>  let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>  luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>> 
>>  // or equivalently, with type inferred from context
>>  luke[keyPath: '.friends[0].name'] // "Han Solo"
>> 
>>  // [SE-0042][SR-3550] Unapplied method references
>>  'String.lowercased()'  // (String) -> String
>>  'String.lowercased(with:)' // (String, Locale?) -> String
>> 
>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
>> the key path (or method reference).
> 
> For what it’s worth, I much rather prefer this approach and was going to 
> suggest it today. In Objective-C, keypaths were just strings so by using a 
> single tick, they still look *almost* like strings, but now they’re safe and 
> checked by the compiler - magical.
> 
> 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

[Ricardo Parada via swift-evolution]

I did not mention single quotes because I was assuming those were reserved for 
string literals.

But if they are available for something like this, it would make it obvious 
where the key path begins and where it ends.  I went through my hypothetical 
code samples, and I don't mind the \ escape character.  For instance:

   let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
   let hasPuppiesPredicate = (\Family.pets).any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)

I don't mind having to use parenthesis sometimes when invoking a method on key 
path for example.

With single quotes it would look like this:

   let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
   let hasPuppiesPredicate = 'Family.pets'.any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)

And creating orderings for example:

   let orderings = [ 'Order.totalAmount'.desc,  'Order.address.zip'.asc ]



> On Apr 6, 2017, at 9:55 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> Re: 
> 
> 
>> On 6 Apr 2017, at 04:13, Xiaodi Wu wrote:
>> 
>>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote:
>>> 
 On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon wrote:
 
 It's worth noting that, if you write `\Person.name.valueType`, this syntax 
 is ambiguous—it could mean "make a key path for the `valueType` property 
 on `name` property of `Person`", or it could mean "make a key path for the 
 `name` property of `Person`, then access the key path's `valueType` 
 property". We can solve this by always interpreting it as the former and 
 requiring parentheses for the latter—that is, 
 `(\Person.name).valueType`—but I thought it was worth calling out 
 explicitly.
>>> 
>>> Good point. 
>>> 
>>> I'm thinking about the hypothetical code examples from previous emails:
>>> 
>>>   let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>>   let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>>   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
>> 
>> That's an interesting point. While `\` alone seems acceptable, I think it's 
>> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
>> Can we maybe consider instead:
>> 
>>  let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
> 
>   // Create a key path and use it
>   let firstFriendsNameKeyPath = 'Person.friends[0].name'
>   luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
> 
>   // or equivalently, with type inferred from context
>   luke[keyPath: '.friends[0].name'] // "Han Solo"
> 
>   // [SE-0042][SR-3550] Unapplied method references
>   'String.lowercased()'  // (String) -> String
>   'String.lowercased(with:)' // (String, Locale?) -> String
> 
> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
> the key path (or method reference).
> 
> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Sean Heber via swift-evolution]

>> That's an interesting point. While `\` alone seems acceptable, I think it's 
>> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
>> Can we maybe consider instead:
>> 
>>  let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
> 
>   // Create a key path and use it
>   let firstFriendsNameKeyPath = 'Person.friends[0].name'
>   luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
> 
>   // or equivalently, with type inferred from context
>   luke[keyPath: '.friends[0].name'] // "Han Solo"
> 
>   // [SE-0042][SR-3550] Unapplied method references
>   'String.lowercased()'  // (String) -> String
>   'String.lowercased(with:)' // (String, Locale?) -> String
> 
> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
> the key path (or method reference).

For what it’s worth, I much rather prefer this approach and was going to 
suggest it today. In Objective-C, keypaths were just strings so by using a 
single tick, they still look *almost* like strings, but now they’re safe and 
checked by the compiler - magical.

l8r
Sean

___
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 LeHew via swift-evolution]

Ah! I will fix those. That is a find replace fail for #keyPath( -> \. Vs 
#keyPath\(.*\) -> \\\1

> On Apr 6, 2017, at 6:16 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I saw those too and forgot to point those out. I assumed they were typos. 
> 
> 
> 
>> On Apr 6, 2017, at 9:03 AM, Ed Wellbrook  wrote:
>> 
>> Apologies if I’ve simply just missed something, but are the trailing right 
>> parentheses in the proposed solution intentional? Reading through the code, 
>> having loosely followed this discussion, I’m really confused.
>> 
>> Examples:
>> 
>> ```
>> // create a key path and use it
>> let firstFriendsNameKeyPath = \Person.friends[0].name)
>>^ this
>> 
>> // optional properties work too
>> let bestFriendsNameKeyPath = \Person.bestFriend?.name)
>>^ this
>> ```
>> 
>> If it’s intentional, I’m very much against it.
>> 
>> Cheers,
>> Ed
>> 
>>> On 6 Apr 2017, at 13:14, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
 
 It is also worth mentioning that, with the sigil, the `keyPath` label may 
 not be so necessary:
 
   print(luke[\.friends[0].name])
   // or, if the suggestion above is accepted
   print(luke[\.friends[0].name\])
>>> 
>>> 
>>> I think the label makes it more obvious, specially when using it with a key 
>>> path variable:
>>> 
>>> let someKeyPath = ...
>>> 
>>> person[
>>> keyPath: someKeyPath]
>>> 
>>> ___
>>> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ben Rimmington via swift-evolution]

Re: 


> On 6 Apr 2017, at 04:13, Xiaodi Wu wrote:
> 
>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote:
>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\

'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:

// Create a key path and use it
let firstFriendsNameKeyPath = 'Person.friends[0].name'
luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"

// or equivalently, with type inferred from context
luke[keyPath: '.friends[0].name'] // "Han Solo"

// [SE-0042][SR-3550] Unapplied method references
'String.lowercased()'  // (String) -> String
'String.lowercased(with:)' // (String, Locale?) -> String

Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
the key path (or method reference).

-- Ben

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

I saw those too and forgot to point those out. I assumed they were typos. 



> On Apr 6, 2017, at 9:03 AM, Ed Wellbrook  wrote:
> 
> Apologies if I’ve simply just missed something, but are the trailing right 
> parentheses in the proposed solution intentional? Reading through the code, 
> having loosely followed this discussion, I’m really confused.
> 
> Examples:
> 
> ```
> // create a key path and use it
> let firstFriendsNameKeyPath = \Person.friends[0].name)
> ^ this
> 
> // optional properties work too
> let bestFriendsNameKeyPath = \Person.bestFriend?.name)
> ^ this
> ```
> 
> If it’s intentional, I’m very much against it.
> 
> Cheers,
> Ed
> 
>> On 6 Apr 2017, at 13:14, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
>>> 
>>> It is also worth mentioning that, with the sigil, the `keyPath` label may 
>>> not be so necessary:
>>> 
>>>print(luke[\.friends[0].name])
>>>// or, if the suggestion above is accepted
>>>print(luke[\.friends[0].name\])
>> 
>> 
>> I think the label makes it more obvious, specially when using it with a key 
>> path variable:
>> 
>> let someKeyPath = ...
>> 
>> person[
>> keyPath: someKeyPath]
>> 
>> ___
>> 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

[David Hart via swift-evolution]

> On 6 Apr 2017, at 15:03, Ed Wellbrook via swift-evolution 
>  wrote:
> 
> Apologies if I’ve simply just missed something, but are the trailing right 
> parentheses in the proposed solution intentional? Reading through the code, 
> having loosely followed this discussion, I’m really confused.
> 
> Examples:
> 
> ```
> // create a key path and use it
> let firstFriendsNameKeyPath = \Person.friends[0].name)
> ^ this
> 
> // optional properties work too
> let bestFriendsNameKeyPath = \Person.bestFriend?.name)
> ^ this
> ```
> 
> If it’s intentional, I’m very much against it.
> 

It’s a typo. It shouldn’t be there.

> Cheers,
> Ed
> 
>> On 6 Apr 2017, at 13:14, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
>>> 
>>> It is also worth mentioning that, with the sigil, the `keyPath` label may 
>>> not be so necessary:
>>> 
>>> print(luke[\.friends[0].name])
>>> // or, if the suggestion above is accepted
>>> print(luke[\.friends[0].name\])
>> 
>> 
>> I think the label makes it more obvious, specially when using it with a key 
>> path variable:
>> 
>> let someKeyPath = ...
>> 
>> person[
>> keyPath: someKeyPath]
>> 
>> ___
>> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ed Wellbrook via swift-evolution]

Apologies if I’ve simply just missed something, but are the trailing right 
parentheses in the proposed solution intentional? Reading through the code, 
having loosely followed this discussion, I’m really confused.

Examples:

```
// create a key path and use it
let firstFriendsNameKeyPath = \Person.friends[0].name)
 ^ this

// optional properties work too
let bestFriendsNameKeyPath = \Person.bestFriend?.name)
 ^ this
```

If it’s intentional, I’m very much against it.

Cheers,
Ed

> On 6 Apr 2017, at 13:14, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
>> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
>> 
>> It is also worth mentioning that, with the sigil, the `keyPath` label may 
>> not be so necessary:
>> 
>>  print(luke[\.friends[0].name])
>>  // or, if the suggestion above is accepted
>>  print(luke[\.friends[0].name\])
> 
> 
> I think the label makes it more obvious, specially when using it with a key 
> path variable:
> 
> let someKeyPath = ...
>  
> person[
> keyPath: someKeyPath]
> 
> ___
> 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

[Ricardo Parada via swift-evolution]

> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
> 
> It is also worth mentioning that, with the sigil, the `keyPath` label may not 
> be so necessary:
> 
>   print(luke[\.friends[0].name])
>   // or, if the suggestion above is accepted
>   print(luke[\.friends[0].name\])


I think the label makes it more obvious, specially when using it with a key 
path variable:

let someKeyPath = ... 
person[keyPath: someKeyPath]

___
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

[Martin Waitz via swift-evolution]

Hello,

> 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
>  
> I
>  really like this version of the proposal with the backslash.

Have you also considered using the backslash when using the KeyPath?

E.g. `person\.bestFriendsName` instead of `person[keyPath: bestFriendsName]`

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

[Haravikk via swift-evolution]

> On 6 Apr 2017, at 06:56, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 6 Apr 2017, at 04:21, Ricardo Parada via swift-evolution 
> > wrote:
> 
>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>>> `name` property of `Person`", or it could mean "make a key path for the 
>>> `name` property of `Person`, then access the key path's `valueType` 
>>> property". We can solve this by always interpreting it as the former and 
>>> requiring parentheses for the latter—that is, 
>>> `(\Person.name).valueType`—but I thought it was worth calling out 
>>> explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>> 
>>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> Couldn't the compiler see there exists no contains property on pets and allow 
> us to avoid the parentheses?

Probably, but IMO it actually looks better, and is clearer, with the brackets 
anyway, so encouraging their use could be a good thing perhaps?___
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

[David Hart via swift-evolution]

> On 6 Apr 2017, at 04:21, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>> `name` property of `Person`", or it could mean "make a key path for the 
>> `name` property of `Person`, then access the key path's `valueType` 
>> property". We can solve this by always interpreting it as the former and 
>> requiring parentheses for the latter—that is, `(\Person.name).valueType`—but 
>> I thought it was worth calling out explicitly.
> 
> Good point. 
> 
>  I'm thinking about the hypothetical code examples from previous emails:
> 
> 
>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)

Couldn't the compiler see there exists no contains property on pets and allow 
us to avoid the parentheses?

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

[David Hart via swift-evolution]

I'm writing my review inline to this one:

> On 6 Apr 2017, at 02:27, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
>> On Wed, Apr 5, 2017 at 4:56 PM 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?
> Full on +1 now. Thank you for reverting the heavy syntax from the previous 
> revision. This makes the feature much more usable, and the future alignment 
> with unbound function references will be welcome in terms of consistency.

I'm also +1 on this new revision.

> I guess I'll throw out my own color for the shed:  Was :: already considered 
> as well? It at least has some precedent in C++ and later Java for similar 
> purposes, and it's not currently an operator in the language. We could have:

I proposed it during discussion. He only counter that I heard was that it was 
potentially reserved for name-spacing.

> Person.foo // a reference to Person's static property foo
> Person::foo // a keypath to Person's instance property foo
> 
> Then, for SE-0042:
> 
> Person::someFunction // a function reference of type (Person, ...other 
> args...) -> Result 
> 
> But that might make the implied case look strange. Would we have to have this?
> 
> print(luke[keyPath: ::.friends[0].name])
> Without the period after the "::", it's inconsistent with other type 
> inference sites, but with it, it's kind of ugly.
> 
> That being said, if the backslash ends up being the operator of record for 
> this feature because other options would be poor choices for other reasons, 
> I'm ok with that.

Same, I have a small preference for :: but I'd be ok with backslash.

> My feedback on the rest of the proposal review bullets is the same as before; 
> I won't repeat it here.
> 
>> 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?
Yep!

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

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

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

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

[Ricardo Parada via swift-evolution]

Here's some hypothetical code example.  Let suppose an extension on key paths 
allows us to invoke desc and asc to help create sort orderings.  This is what 
it would look using the two different notations:

// Order by totalAmount descending, then by address.zip ascending
let orderings = [ (\Order.totalAmount).desc,  (\Order.address.zip).asc ]
let orderings = [ \Order.totalAmount\.desc,  \Order.address.zip\.asc ]

The second one saves one character every time you want to invoke a method on 
the key path but I would have to go back and add the left parenthesis, which 
could be a bit annoying as I'm typing these things in, unless the editor were 
to come to the rescue add the left parenthesis automatically somehow.  But 
anyways, I can go with either one.

Still +1 on the proposal.  :-)


> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu  wrote:
> 
> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution 
> > wrote:
> 
>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>> It's worth noting that, if you write `\Person.name.valueType`, this syntax 
>> is ambiguous—it could mean "make a key path for the `valueType` property on 
>> `name` property of `Person`", or it could mean "make a key path for the 
>> `name` property of `Person`, then access the key path's `valueType` 
>> property". We can solve this by always interpreting it as the former and 
>> requiring parentheses for the latter—that is, `(\Person.name).valueType`—but 
>> I thought it was worth calling out explicitly.
> 
> Good point. 
> 
>  I'm thinking about the hypothetical code examples from previous emails:
> 
> 
>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> It is also worth mentioning that, with the sigil, the `keyPath` label may not 
> be so necessary:
> 
>   print(luke[\.friends[0].name])
>   // or, if the suggestion above is accepted
>   print(luke[\.friends[0].name\])

___
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

[Xiaodi Wu via swift-evolution]

On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It's worth noting that, if you write `\Person.name.valueType`, this syntax
> is ambiguous—it could mean "make a key path for the `valueType` property on
> `name` property of `Person`", or it could mean "make a key path for the
> `name` property of `Person`, then access the key path's `valueType`
> property". We can solve this by always interpreting it as the former and
> requiring parentheses for the latter—that is,
> `(\Person.name).valueType`—but I thought it was worth calling out
> explicitly.
>
>
> Good point.
>
>  I'm thinking about the hypothetical code examples from previous emails:
>
>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
>
>
That's an interesting point. While `\` alone seems acceptable, I think it's
unfortunate that we'll have `(\...)` and `\(...)` both in the language.
Can we maybe consider instead:

let firstFriendsNameKeyPath = \Person.friends[0].name\

It is also worth mentioning that, with the sigil, the `keyPath` label may
not be so necessary:

print(luke[\.friends[0].name])
// or, if the suggestion above is accepted
print(luke[\.friends[0].name\])
___
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

[Charles Srstka via swift-evolution]

+1. This looks fantastic.

Charles

> On Apr 5, 2017, at 6:56 PM, 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

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

> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> It's worth noting that, if you write `\Person.name.valueType`, this syntax is 
> ambiguous—it could mean "make a key path for the `valueType` property on 
> `name` property of `Person`", or it could mean "make a key path for the 
> `name` property of `Person`, then access the key path's `valueType` 
> property". We can solve this by always interpreting it as the former and 
> requiring parentheses for the latter—that is, `(\Person.name).valueType`—but 
> I thought it was worth calling out explicitly.

Good point. 

 I'm thinking about the hypothetical code examples from previous emails:


   let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
   let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)

___
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

[Brent Royal-Gordon via swift-evolution]

> On Apr 5, 2017, at 6:41 PM, Brent Royal-Gordon  wrote:
> 
> I don't adore the `\` syntax because I don't quite see the underlying logic 
> of that symbol, but it's a *massive* improvement over the old `#keyPath(Type, 
> .path)` mess, and in all other respects I remain extremely positive on this 
> proposal.

I realized after sending that this may have sounded more negative than I meant 
it to be. The backslash is not perfect, but it is more than acceptable, and I'm 
sure I'll get used to it. I recommend the proposal be accepted.

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

[Brent Royal-Gordon via swift-evolution]

> 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?
I don't adore the `\` syntax because I don't quite see the underlying logic of 
that symbol, but it's a *massive* improvement over the old `#keyPath(Type, 
.path)` mess, and in all other respects I remain extremely positive on this 
proposal.

It's worth noting that, if you write `\Person.name.valueType`, this syntax is 
ambiguous—it could mean "make a key path for the `valueType` property on `name` 
property of `Person`", or it could mean "make a key path for the `name` 
property of `Person`, then access the key path's `valueType` property". We can 
solve this by always interpreting it as the former and requiring parentheses 
for the latter—that is, `(\Person.name).valueType`—but I thought it was worth 
calling out explicitly.

> 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?
Pretty much.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Just Objective-C. This is much better.

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

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

[Harlan Haskins via swift-evolution]

+1 for using ::

It’s got precedence in many other languages (C++, Java 8+, Kotlin) to reference 
static methods, and it’s sufficiently different enough from `.` to avoid 
confusing people.

While I personally resist letting C++ influence Swift syntactically, this makes 
a lot of sense to me.

— Harlan

> On Apr 5, 2017, at 8:27 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Wed, Apr 5, 2017 at 4:56 PM 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?
> Full on +1 now. Thank you for reverting the heavy syntax from the previous 
> revision. This makes the feature much more usable, and the future alignment 
> with unbound function references will be welcome in terms of consistency.
> 
> I guess I'll throw out my own color for the shed:  Was :: already considered 
> as well? It at least has some precedent in C++ and later Java for similar 
> purposes, and it's not currently an operator in the language. We could have:
> 
> Person.foo // a reference to Person's static property foo
> Person::foo // a keypath to Person's instance property foo
> 
> Then, for SE-0042:
> 
> Person::someFunction // a function reference of type (Person, ...other 
> args...) -> Result 
> 
> But that might make the implied case look strange. Would we have to have this?
> 
> print(luke[keyPath: ::.friends[0].name])
> 
> Without the period after the "::", it's inconsistent with other type 
> inference sites, but with it, it's kind of ugly.
> 
> That being said, if the backslash ends up being the operator of record for 
> this feature because other options would be poor choices for other reasons, 
> I'm ok with that.
> 
> My feedback on the rest of the proposal review bullets is the same as before; 
> I won't repeat it here.
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

On Wed, Apr 5, 2017 at 4:56 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> 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?
>
> Full on +1 now. Thank you for reverting the heavy syntax from the previous
revision. This makes the feature much more usable, and the future alignment
with unbound function references will be welcome in terms of consistency.

I guess I'll throw out my own color for the shed:  Was :: already
considered as well? It at least has some precedent in C++ and later Java
for similar purposes, and it's not currently an operator in the language.
We could have:

Person.foo // a reference to Person's static property foo
Person::foo // a keypath to Person's instance property foo

Then, for SE-0042:

Person::someFunction // a function reference of type (Person, ...other
args...) -> Result

But that might make the implied case look strange. Would we have to have
this?

print(luke[keyPath: ::.friends[0].name])

Without the period after the "::", it's inconsistent with other type
inference sites, but with it, it's kind of ugly.

That being said, if the backslash ends up being the operator of record for
this feature because other options would be poor choices for other reasons,
I'm ok with that.

My feedback on the rest of the proposal review bullets is the same as
before; I won't repeat it here.


>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

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