[swift-evolution] RFC: didset and willset
Erica Sadun
erica at ericasadun.com
Fri May 20 12:55:22 CDT 2016
> On May 20, 2016, at 11:52 AM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On May 20, 2016, at 10:48 AM, Erica Sadun <erica at ericasadun.com> wrote:
>>
>>
>>> On May 20, 2016, at 11:43 AM, Chris Lattner <clattner at apple.com> wrote:
>>>
>>>
>>>> On May 20, 2016, at 10:41 AM, Erica Sadun <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
To be clear before I put anything together, `nonreturning`, yes?
-- E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/8eac52f9/attachment.html>
More information about the swift-evolution
mailing list