[swift-evolution] Smart KeyPaths

[Charles Srstka]

> On Mar 19, 2017, at 4:15 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>> 
>>>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> I disagree. How the reader is supposed to now there is a static property or not ? Having readable code is more important than having easy to write code.
>>>> 
>>>> I’ve got to agree with this. With the proposed syntax, it’s unclear whether you’re referring to a static property or a key path. It’s going to cause confusion. There needs to be some kind of syntactic way to differentiate the two.
>>> 
>>> How often do you have a property with the exact same name and type on both the instance and type? When you *do* have one, how often would it be better off with a name like `defaultFoo` instead of plain `foo`?
>>> 
>>> Why is this a problem for keypaths, but not for unbound methods?
>>> 
>>> How is this different from a hundred other places in Swift where we allow overloading and tolerate ambiguity in order to enjoy nicer syntax?
>>> 
>>> When, in practice, do you expect this to cause trouble?
>> 
>> Even if there *isn’t* a property with the same name, it’s still confusing, because to a reader unfamiliar with the code, it’s not clear what you’re looking at.
> 
> This is true of many things.  It is why IDEs make type information readily available.

Is clarity not a thing to be desired?

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170319/bcf1b398/attachment.html>