[swift-evolution] Smart KeyPaths

[Vladimir.S]

On 22.03.2017 6:01, Ricardo Parada via swift-evolution wrote:
> Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards.
>
> Maybe we'll have to start looking at emojis :-)

IMO syntax for method references should match the same for key paths, and 
also that both these features desire to be highlighted by that syntax. I 
mean we should understand from first look at code what is happening here.

So my suggestion is to discuss if we can change syntax for method reference 
and apply the same syntax for key paths. Is it worth to discuss this and 
try to 'invent' the best syntax?

For example, '@' operator-like syntax could be proposed:

struct Thing {
	var name = ""
}

struct Bag {
	func foo() {print("foo")}
	var things = [Thing(name:"first")]
}

let ref = @Bag.foo
// probably we should require '()' here to see that this a method ref, not path
//let ref = @Bag.foo()

var bag = Bag()
ref(bag)()

let path = @Bag.things[0].name

bag at path
bag at .things[0].name
bag at Bag.things[0].name
bag.things[0]@.name
bag.things[0]@Thing.name

even these IMO better that just bag[path]
bag@[path]
bag@[.things[0].name]
bag[@path]
bag[@.things[0].name]

IMO it looks and reads("bag at path") well, the syntax is very special, no 
confusion if we access the subscript or the key path, if you ever know 
about method refs or key paths - you see what is happening here. If you 
don't know - you will ask yourself "what does this '@' mean" and have to 
read docs.

Or variant with # modifier:
let ref = #Bag.foo
let path = #Bag.things[0].name
bag#path
bag#.things[0].name
bag#Bag.things[0].name

But it seems I like it less than with @.

>
>
>
>> On Mar 21, 2017, at 9:13 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>>
>> Sent from my iPad
>>
>>> On Mar 21, 2017, at 8:00 PM, Ben Rimmington <me at benrimmington.com> wrote:
>>>
>>> Re: <https://github.com/apple/swift-evolution/pull/644>
>>>
>>>> On 21 Mar 2017, at 13:16, Matthew Johnson wrote:
>>>>
>>>> I think the language is best served if all unbound members are accessible using the same syntax.  IMO this proposal does the right thing by choosing consistency with existing language features.  The current syntax for unbound methods works and hasn't caused any confusions I'm aware of in practice.
>>>>
>>>> I don't feel too strongly about what syntax we use as long as it's concise and works for accessing all unbound members.  If people want to make the case for using `#` instead of `.` to do this I won't object but I won't be a vocal advocate either.  However, I think that should be an independent proposal if somebody wants to pursue it rather than a bike shed on this proposal which would only lead to inconsistency between key paths and unbound methods if it succeeds.
>>>
>>> A new syntax for key paths and function references could resolve:
>>>
>>> * the "compound name syntax for nullary functions" problem;
>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032890.html>
>>>
>>> * the source-breaking change of SE-0042 (if reconsidered for Swift 4);
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
>>
>> I would like to see both of these problems resolved.  If somebody put together a solid proposal for this I would probably support it (depending on details of course).
>>
>>>
>>> -- Ben
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>