Sent from my iPhone
> On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon <br...@architechies.com> >>> wrote: >>> >>>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >>>> <swift-evolution@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. > > 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 > > _______________________________________________ > 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
