[swift-evolution] RFC: didset and willset

Brandon Knope bknope at me.com
Fri May 20 17:02:29 CDT 2016


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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


More information about the swift-evolution mailing list