[swift-evolution] RFC: didset and willset
bknope at me.com
Fri May 20 11:06:55 CDT 2016
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,
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
>> `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).
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution