[swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

[Brent Royal-Gordon]

> 	* 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