[swift-evolution] RFC: didset and willset

[Brandon Knope]

I think my problem stems from the fact that some of these keywords aren't in the normal place we'd find a keyword. Some are acting like properties and others are acting like methods:

someClass.dynamicType looks like a normal property on an object. 
someClass.dynamictype just looks unnatural as a result. 

didSet/willSet also look like methods and not really keywords. They also contain descriptive names that are an action of doing something or something about to be down, like a normal method name would usually convey. 

I'm not sure there is a perfect way to reconcile these two things: being a keyword and following those rules yet not really seeming like one read or seen. 

Would it be easier not to make these keywords somehow? I.E. dynamicType on a protocol all classes conform to which would end that debate once and for all. 

Just some thoughts, 
Brandon 

Sent from my iPad

> On May 20, 2016, at 2:11 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I may be wrong but I don't remember any other case of a keyword in
>>> Swift composed of two or more words, so I believe these should be
>>> exceptions.
>> 
>> `typealias` and `associatedtype` are the main examples; there were huge catfights on swift-evolution about whether the latter should be `associatedtype`, `associatedType`, or `associated_type`. There are also a number of attributes like `@noescape` and `@discardableResult`, which aren't 100% consistent.
> 
> 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).
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution