[swift-evolution] [Review] SE-0030 Property Behaviors
mailing at xenonium.com
Sat Feb 13 07:00:08 CST 2016
This kind of shortcut may be ambiguous. How do you handle the case where both the underlying type and the property declare the same method ?
How do you handle the case where a property has more than one behavior ?
If the underlying property is not an Optional, being able to set it to nil is confusing, and if it is Optional, how would you now that setting it to nil should clear the lazy behavior and not affect the value nil to the underlying property.
> Le 13 févr. 2016 à 01:46, Myles La Verne Schultz via swift-evolution <swift-evolution at swift.org> a écrit :
> My apologies, I did not intend to be picky. That case involving the use of .clear() just seemed like the most obvious. My overall point was that if one has to reference the behavior every time the property is used, that becomes cumbersome and not really any better than what we have now. So being able to apply property behaviors without have to
> foo.[behavior].instance = 1
> etc. (pardon if I made any mistakes above, I was typing that from what I remembered from the proposal)
> when we need to use them, would be more ideal. In other words,
> foo = 1
> foo = nil
> I really like the idea of property behaviors, I just don’t like the syntax for how they are invoked. That’s what I meant. I really didn’t mean to mince words or be picky. It was just a suggestion to help simplify the syntax if possible.
>> On Feb 12, 2016, at 6:22 PM, David Hart <david at hartbit.com> wrote:
>>> On 12 Feb 2016, at 03:32, Myles Schultz via swift-evolution <swift-evolution at swift.org> wrote:
>>> Having to use dot syntax every time doesn't feel right. When it comes to the having to use .clear(), that really doesn't feel right. Setting value to nil seemed so much cleaner and simpler.
>> 1) behaviors exist for implementing more than lazy, so making an argument about the calling syntax for 'clear' seems a bit too not picky for me.
>> 2) In the case of lazy, the property's type is often not optional. So setting the value to nil is a non-sensical from a type-checker point of view.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution