[swift-evolution] RFC: didset and willset

[Patrick Smith]

Yes, I don’t think they are the same as keywords, and should stay camelCase. Especially if you can define your own with behaviours — it will feel like you are defining your own keywords, which is wrong.

userDefined
languagedefined

I’d much prefer to just stay with willSet and didSet. Let’s see what behaviours turn out to be, and design some pinned down rules then.

As Erica said in her post about Swift 3, "Make big breaking changes later and once rather than sooner and multiple times.”
http://ericasadun.com/2016/05/18/if-i-had-my-druthers-swift-2-2-swift-3-0-abis-etc/

Chris said "In practice, we can accept both spellings for a long time at no harm to anyone.”, so hopefully as proposed Swift 3 would support both willSet/didSet & willset/didset anyway. So this is a pointless addition with wishes for consistency that won’t be known until property behaviours.

The other proposals for dynamicType etc sound fine to me.


> On 21 May 2016, at 11:03 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
> 
> If accessors are defined by the developer who designs a property behavior then I do not see them as keywords. Or am I wrong?
> 
> That is why I would prefer them lowerCamelCase. 
> 
> 
> On May 20, 2016, at 1:50 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution