> On May 20, 2016, at 11:52 AM, Chris Lattner <[email protected]> wrote:
> 
>> 
>> On May 20, 2016, at 10:48 AM, Erica Sadun <[email protected]> wrote:
>> 
>> 
>>> On May 20, 2016, at 11:43 AM, Chris Lattner <[email protected]> wrote:
>>> 
>>> 
>>>> On May 20, 2016, at 10:41 AM, Erica Sadun <[email protected]> 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

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to