[swift-evolution] RFC: didset and willset

[Matthew Johnson]

> On May 20, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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)
>> 	• Terms of art may be exempted from casing rules.
>> 	• Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.
> 
> I started working on expanding this and ended up creating a general set of guidelines for naming language entities in Swift. Oops. You might want to just use the relevant subset.
> 
> * * *
> 
> Keywords:
> 
> 1. Appear anywhere in the grammar appropriate for their purpose.
> 2. Have no prefix.
> 3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
> 4. May be any part of speech appropriate for the use, but are usually nouns, verbs, conjunctions, or prepositions, rarely adjectives or adverbs.
> 
> Declaration modifiers:
> 
> 1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with attributes.
> 2. Have no prefix.
> 3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
> 4. Are usually adjectives.
> 
> Attributes:
> 
> 1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with declaration modifiers.
> 2. Are prefixed with `@` symbols.
> 3. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
> 	* Prefixes like "auto" and "non" do not introduce new words.
> 4. Are usually adjectives or involve an adjective.
> 	* When constructing an attribute name from a verb, use the "-ing" form (e.g. "escaping", not "escape") to turn it into an adjective.
> 	* When negating a term, use the "non" prefix.
> 
> Build configuration statements:
> 
> 1. Appear where statements or declarations are valid.
> 2. Are prefixed with `#` symbols.
> 3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
> 	* If block-scoped, they run until a matching `#end<foo>` statement.
> 4. May be any part of speech appropriate for the use, but are usually verbs, conjunctions, or prepositions.
> 
> Compiler-expanded expressions:
> 	
> 1. Are prefixed with `#` symbols.
> 2. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
> 3. Are usually nouns, but may be adjectives if they have parameters and are testing for that trait.[1]
> 4. Appear in expressions.
> 
> As always in Swift naming, you may deviate from these rules to preserve a widely-used term of art if it is a very close match for the meaning of the entity.
> 
> [1] The adjective rule here is for #available. Should that be #isAvailable, though? That would more closely match our usual rules about Boolean expressions.

You haven’t discussed behavior accessors here, presumably because you’re not counting them (and therefore didSet and willSet) language entities.  Is that correct?  

It is probably worth discussing them here as well since this thread is about changing the names of what are going to be behavior accessors in the future.

> 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution