[swift-evolution] Smart KeyPaths

[Charles Srstka]

> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon <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.

Unbound methods are annoying too. At least with them, though, there are *usually* naming conventions that differentiate the two from each other (but not always. Quick, between FileManager, NSParagraphStyle, IOBluetoothHostController, NSTimeZone, and and NSUserNotificationCenter, which ones require you to put parens after the ‘default’ accessor, and which don’t?).

Charles

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