Revisiting SE-0098 (rename didSet into didset) - Is the rationale to reject still valid?

[ensan-hcl (ensan)]

SE-0098, which aimed to rename didSet/willSet into didset/willset was rejected with the following rationale.

The review of SE-0098: "Lowercase didSet and willSet for more consistent keyword casing" ran from May 24…30, 2016. The proposal is rejected for Swift 3.

The feedback on the proposal from both the core team and the community was that these should remain camel cased, particularly given that they may become user-definable aspect names in a future release.

Many thanks to Erica Sadun for driving this discussion and writing the proposal. This was an important topic for the community and core team to re-evalute.

For those of us who participated in this forum in 2021, this rationale was difficult to understand. I read this thread and SE-0030, and found that the 'user-definable aspect names in a future release' is mostly relating to a feature of 'property behaviors'. And in 2016, it had been thought that didSet and willSet would be one of 'accessors' which would be also definable by users. Therefore, people in the discussion worried that renaming didSet into didset would cause users to name their custom accessors in lowercase, and rejected the proposal.

(Please tell me if I'm misunderstanding)

I agree this was convincing reason in 2016. However, now there is an introduced alternative feature 'property wrappers'. When it was called 'property delegates', the author of the proposal explained the difference as:

@Douglas_Gregor

Property delegates address a similar set of use cases to property behaviors , which were proposed and reviewed in late 2015/early 2016. The design did not converge, and the proposal was deferred. This proposal picks up the thread, using much of the same motivation and some design ideas, but attempting to simplify the feature and narrow the feature set.

As this quote, property wrappers are alternative feature of property behaviors. Now property wrappers were introduced and we can say property behaviors won't be added in the future. So now there is nothing to worry to rename didSet/willSet into didset/willset, except that it is a source breaking change .

Upon Swift 6: Solve inconsistency within the language

The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother. I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet di…

As said in that thread, Swift6 would be a great opportunity to fix this inconsistency, and I think SE-0098 should be revisited.

[cukr]

For reference, here's the current state of keyword capitalization:

• single word, lowercase:
  most of the keywords
• single word, capitalized
  Any, Self, Protocol, Type
• two words, lowercase
  associatedtype, fileprivate, fallthrough, inout, precedencegroup, typealias, #dsohandle, #elseif, #endif
• two words, camel case
  #colorLiteral, #fileID, #fileLiteral, #filePath, #imageLiteral, #keyPath, #sourceLocation, didSet, willSet

[Jean-Daniel]

If one is inconsistent in this list, this is #dsohandle.

[ensan-hcl (ensan)]

I agree. It seems that #dsohandle was introduced when people considered #identifier should be all-lowercase. But now it is definitely inconsistent.

apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md