[swift-evolution] RFC: didset and willset

[Matthew Johnson]

> On May 20, 2016, at 3:41 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
>> On May 20, 2016, at 11:52 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> On May 20, 2016, at 10:48 AM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>> On May 20, 2016, at 11:43 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>>> On May 20, 2016, at 10:41 AM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>>>>>> Right, but the catfight had a clear outcome:
>>>>>>>> 
>>>>>>>> 1) keywords are conjoined
>>>>>>>> 2) attributes are lower camel cased.
>>>>>>>> 3) attributes should use “non” not “no”.  noescape should be nonescaping (and thus no camel bump).
>>>>>>> 
>>>>>>> Would you be in favor of a proposal that cleans all of this up at once and establishes this standard for all new features?  I don't mind the change and think consistency is a good idea, I just think it doesn't make sense to keep doing these as one-off changes.
>>>>>> 
>>>>>> I’d prefer one proposal to cover didset/willset and one to cover nonescaping (and any other nofoo attributes left).    They will raise different sorts of discussion, even though they both seem obvious to me.
>>>>> 
>>>>> Before putting together a proposal, are there any other de-facto rules besides the three already listed that touch on naming keywords and attributes? (I suppose no snake case is a given)
>>>> 
>>>> I think that these are the relevant rules.  As I mentioned upthread, .dynamicType is broken for a different reason, and thus leads to a different solution (it should be a global function in the stdlib, not a propery).
>>>> 
>>>> -Chris
>>> 
>>> Separate action items:
>>> 
>>> * Move dynamicType to standard library as a global function
>>> * Rename didSet and willSet to lowercase to conform to Swift standard of conjoined lowercase keywords.
>> 
>> Sounds great.
>> 
>>> * Rename noescape to nonescaping to conform to Swift standard of "non"-modified attributes
>> 
>> I just looked and the one other wrong one we have is “noreturn”.  It would be great to tackle nonescaping and whatever noreturn should be in the same proposal.
>> 
>> Thanks Erica!
>> 
>> -Chris
> 
> Please look through and comment:
> 
> https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407 <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407>
> 
> Gist contents pasted below.

Looks good.  I’m glad to see a proposal to address this holistically.  :)  

I do support Brent’s argument that keywords which syntactically appear in the same syntactic location as user-defined names should follow the same convention as those user-defined names.  This means, for example, that dynamicType already has the correct case even though it is a keyword.  I would like to see this exemption added to the proposal.

Also, with this in mind I would like to see more discussion about the naming convention the community prefers for user-defined behavior accessors (under the assumption that they will make it eventually).  If we agree on lowercase for user-defined accessors (which is Chris’s stated preference) I support the change to willset and didset.  

However, it is possible that this discussion would result in he community agreeing on lower came case for user-defined behavior accessors.  If that is the result then we should not change them.  

Most specifically, I would like the discussion to consider whether there may be reallylongbehavioraccessornames that will be completely unreadable in all lowercase (I’m intentionally giving a very extreme example here).  Swift favors clarity over conciseness when necessary.  Can we really be sure that all accessors for all behaviors will be concise enough for all lowercase names to make sense?

-Matthew

> 
> -- Erica
> 
> 
> Adopting consistent keyword casing in Swift
> 
> Proposal: TBD
> Author: Erica Sadun <https://github.com/erica>
> Status: TBD
> Review manager: TBD
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#introduction>Introduction
> 
> This proposal adopts consistent conjoined keyword lowercasing.
> 
> Swift-evolution thread: RFC: didset and willset <http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534>
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#motivation>Motivation
> 
> Swift is an opinionated language. One opinion it adheres to is that keywords should use conjoined lowercasing. Conjoined lowercase terms already in the language include typealias, associatedtype, and fallthrough. Using this casing style enables programmers to treat keywords as atomic concepts. This proposal formalizes this rule and fixes current inconsistencies. 
> 
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#swift-casing-rules-roadmap>Swift Casing Rules Roadmap
> 
> This proposal addresses the first of the following Swift casing rules:
> 
> Keywords use lower case conjoined naming.
> Attributes use lower camel cased naming.
> Attributes use “non” prefixes in preference to "no" prefixes.
> Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
> Swift eschews snake casing. (See also: SE-0028 <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>)
> Terms of art may be exempted from casing rules.
> Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#swift-language-cleanup-roadmap>Swift Language Cleanup Roadmap
> 
> This proposal is part of a series that will:
> 
> Normalize casing to lower conjoined names.
> Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
> Move dynamicType to the standard library as a global function.
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#detailed-design>Detailed Design
> 
> Upon adoption, Swift will rename didSet and willSet to willset and didset. Future expansions to the language will follow this adopted rule, for example didchange.
> 
> This proposal deliberately omits the dynamicType keyword, which will be addressed under separate cover: to be moved to the standard library as a standalone global function.
> 
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#impact-on-existing-code>Impact on Existing Code
> 
> This proposal requires migration support to rename keywords that use the old convention to adopt the new convention. This is a simple substitution that should limit effect on code.
> 
> This proposal recommends deprecating old-style keywords in Swift 2.3 and removing them in Swift 3.
> 
>  <https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#alternatives-considered>Alternatives Considered
> 
> Not adopting this rule for Swift.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/1255fe2f/attachment-0001.html>