I agree with you completely. I tried to argue the same thing but maybe not as 
eloquently :P. 

I don't think the qualification should be that all keywords must look a 
specific way but more like "where does this fit in naturally". 

dynamicType is masquerading as a property and didSet and willSet are acting 
like methods and I think they should look as such unless they are changed. 

Brandon 

On May 20, 2016, at 4:02 PM, Brent Royal-Gordon via swift-evolution 
<[email protected]> wrote:

>>>> When we introduce property behaviors, the surface level syntax for this 
>>>> sort of thing is likely to remain the same, and it therefore stands to 
>>>> reason that the behavior “accessors” would follow the same convention as 
>>>> keywords.
>>> 
>>> Yes, but what will the conventions be? Is the accessor for the "did change" 
>>> behavior going to be `didchange` or `didChange`?
>> 
>> I’m arguing for “didchange”.  
>> 
>> To be clear, this is just my personal opinion, but even in the context of a 
>> general user-defined behavior, these things seem extremely "keyword like” 
>> from the users perspective.  To a user of a behavior, these aspects are not 
>> arbitrary user defined names, they are specific things that you can pick 
>> from.  The existing accessors clearly work the same way.
> 
> Okay. That was not the answer I expected :^), but if that is your answer, and 
> if you're pretty confident in that answer, then I support changing willSet 
> and didSet.
> 
>>> *That*—not some general rule about keywords which is primarily designed to 
>>> address things like `fallthrough` and `associatedtype`—is what I think 
>>> `willSet` and `didSet` ought to match. Users do not care whether something 
>>> comes out of the standard library or the language grammar; they care 
>>> whether it has the feel of other things which fit that syntactic slot.
>> 
>> I don’t understand what you’re trying to say here.
> 
> I'm trying to articulate a general rule, that when there is a built-in thing 
> that goes alongside user-defined things, the built-in thing should be 
> capitalized like the user-defined things even if it's implemented as a 
> "keyword".
> 
> That is, nobody cares whether dynamicType is a keyword or an extension on 
> Any, and nobody cares whether willSet is a keyword or an accessor for a 
> built-in property. Since they behave like something else in the grammar, they 
> should be spelled like that thing, too.
> 
>>> (For instance, a perhaps controversial opinion: I think `dynamicType` is 
>>> properly capitalized for the syntactic 
>>> slot it's in.
>> 
>> As I mentioned down-thread, the problem with .dynamicType is that it is in 
>> the wrong slot :-)
> 
> I don't necessarily disagree. What I'm saying is, fake properties should be 
> capitalized like real properties, and fake accessors should be capitalized 
> like real accessors.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to