> * What is your evaluation of the proposal? If we are absolutely, 100% sure that we are going to use lowercase naming for other accessors, including user-defined ones for property behaviors, then I see no reason not to do this now. If we are less than, say, 95% sure, I don't think we should do this yet. Changing from `willSet` to `willset` in Swift 3.2 or Swift 4 has a much smaller cost than changing to `willset` in Swift 3 and then back to `willSet` in a future version; jerking users around like that is likely to upset them.
And I don't think we should be 95% sure that all future accessors will be all-lowercase, because I think making them all-lowercase would be a *very* dubious decision, for several reasons: 1) `willset` and `didset` are less readable than `willSet` and `didSet`. 2) It is likely that many user-defined accessors will be impacted even more severely by all-lowercasing than `willset` and `didset`. Try to parse out names like `willlock` or `xmlid` or `enqueueforreading`, compared to the mixed-case `willLock`, `xmlID`, and `enqueueForReading`, and you'll see what I mean. 3) User-defined accessors will not only be defined; they will also be called. And these calls will look very strange indeed, given their keyword-like capitalization. 4) Keywords are all-lowercase because they are so familiar, and so intrinsic to the language's grammar, that an experienced Swift developer does not really read them so much as recognize them. But `willSet` and `didSet` *do* need to be read, because they are very similar keywords (one-character length difference) which both appear in the same context. And user-defined accessors will need to be read even more, because their names will be arbitrary and quite possibly used infrequently. The requirements of an accessor name are simply different from a declaration like `associatedtype`. 5) Keywords are *also* all-lowercase because they are rare multi-word examples of a class of names which are typically short and single-word. For instance, `associatedtype` and `typealias` belong to a class of declaration keywords which include `let`, `var`, `func`, `subscript`, `init`, `deinit`, `class`, `struct`, `enum`, `protocol`, and `extension`, all single-word keywords. `fallthrough` belongs to the same class as `break`, `continue`, `return`, `throw`, and `try`, as well as arguably `if`, `else`, `guard`, `switch`, `case`, `where`, `while`, `repeat`, `for`, `do`, and `catch`, again all single-word keywords. By contrast, I doubt that very many accessors will be single-word; currently we have two single-word ones and two multi-word ones, and most examples of user-defined accessors I've seen have been multi-word. Because I think we should probably not adopt all-lowercase user-defined accessor names, and because I think it is *much* better to make this change later than to make it now and undo it later, I think we probably should defer this proposal until the property behavior design has solidified. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, but *only* if we are certain that this is the direction we want accessors to take—and I don't think we should be that certain. > * Does this proposal fit well with the feel and direction of Swift? Maybe. It depends on the design of future features. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? N/A. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Participated in previous discussions. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
