[swift-evolution] [Review] SE-0030 Property Behaviors

Myles Schultz myleslschultz at icloud.com
Thu Feb 11 20:32:59 CST 2016

I like the idea behind using protocols for behaviors, but the more I think about it, the more I'm not in love with the way it is invoked. 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. 

Also, why can't we apply the behaviors described but keep the keyword where it is. 

lazy var foo: Int

You would t have change so much code, it's familiar and I like the the keyword lazy seems to be modifying the var when it typed before it. It's acting like and adjective. Essentially, that's what the behavior protocols are doing--describing the behavior of a given property and acting like an adjective. 

Does anyone else feel the same on these points?


Sent from my iPhone

> On Feb 11, 2016, at 4:40 PM, Trent Nadeau via swift-evolution <swift-evolution at swift.org> wrote:
> From what I've seen @ is used for annotations, which apply to declarations. I've never seen them used as an attribute like foo. at bar.
> foo.#behavior(lazy).clear() seems clearer than foo.[lazy].clear().
>> On Thu, Feb 11, 2016 at 4:36 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> > Where [lazy] is currently used, could the syntax instead be #behavior(lazy)? That prevents a possible future naming clash, keeps the # meaning compiler-magic, and doesn't use the [], which is contentious.
>> I think that if we go down this road, @behavior(lazy) or just @lazy is strictly superior. We already have the @ sigil for attributes; we don't need to introduce another sigil for no apparent reason.
>> (But unless we're going to use the latter syntax and say "all @s are behaviors, we just haven't formalized func/type/etc. behaviors yet" so we finally have an idea of what @ means, I don't think either of these syntaxes is better than the one proposed.)
>> --
>> Brent Royal-Gordon
>> Architechies
> -- 
> Trent Nadeau
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160211/0c7b9f31/attachment.html>

More information about the swift-evolution mailing list