[swift-evolution] RFC: didset and willset
clattner at apple.com
Fri May 20 12:50:42 CDT 2016
On May 19, 2016, at 11:34 PM, Brent Royal-Gordon <brent at architechies.com> 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.
> If I write a JSON behavior, is my accessor going to be `toJSON` or `tojson`?
If you’re writing a JSON behavior, including “JSON” in the accessor would be a needless word. The names for the accessors should describe “aspects” of the behavior they are implementing, not the behavior itself.
That said, you’re right that this could come up. When and if we have a specific example to discuss, I'm sure we can figure out a reasonable policy.
> *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.
> (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 :-)
> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, accessors.
I agree with your believe that we should treat these just like user-defined accessors. So lets assume we had an “observed” behavior that had didset/willset aspects that can be specified. To the implementor of the behavior, these are terms that they define, but to users of the behavior, they are indistinguishable from keywords.
More information about the swift-evolution