[swift-evolution] RFC: didset and willset
Erica Sadun
erica at ericasadun.com
Fri May 20 12:41:26 CDT 2016
> On May 20, 2016, at 11:39 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> On May 20, 2016, at 7:24 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>>
>>> On May 20, 2016, at 1: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).
>>
>> 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)
-- E
More information about the swift-evolution
mailing list