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@path
[email protected][0].name
[email protected][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
<[email protected]> wrote:
Sent from my iPad
On Mar 21, 2017, at 8:00 PM, Ben Rimmington <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
