> On Mar 19, 2017, at 4:15 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon <br...@architechies.com >>> <mailto: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. > > This is true of many things. It is why IDEs make type information readily > available.
Is clarity not a thing to be desired? Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
