> 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 <mailto: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. 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
