[swift-evolution] RFC: didset and willset
matthew at anandabits.com
Fri May 20 09:26:27 CDT 2016
Sent from my iPad
On May 20, 2016, at 1:34 AM, 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`? If I write a JSON behavior, is my accessor going to be `toJSON` or `tojson`?
> *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.
+1. Standard library behaviors should use a convention that is appropriate to recommend for user behaviors as well.
> (For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic slot it's in. That's not to say I think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is more appropriate than `foo.dynamictype` would be.)
+1. 'foo.dynamictype' seems strange to me.
> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, accessors. If user-defined accessors are not going to go into that syntactic slot, or if they are going to have all-lowercase accessor names, then by all means, lowercase `willSet` and `didSet`. But if user-defined accessors are going to be mixed-case, then `willSet` and `didSet` should be too. And if we aren't sure whether user-defined accessors will be all-lowercase or mixed case, then let's not jump the gun and make a change that we're likely to reverse later.
> Brent Royal-Gordon
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution