<div dir="ltr">> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md</a><br><br>As for the proposal itself:<br><br>> • What is your evaluation of the proposal?<br><br>+1.<br><br>However, like Brent says: "this proposal is a good core for property behaviors, but alone, I don't think it carries its own weight. It will need at least a couple of the items in "Future Directions" section before it's really worth having."<br><br>In the fact, i prefer the first version of the proposal, the first version is more "must do", this one is "just nice".<div><br></div><div><div>And i'm not convincing of the syntax to, i prefer something like that:</div><div>Pipe ( | | ) operator instead `[ ]`, `{ }` or `< >`</div><div><br></div><div>var |lazy| a = ...</div><div>var |observable| b = ...</div><div><br></div><div>and this to access:</div><div><br></div><div>a<b>#</b>clear() // yes, without the dot.</div><div>b<b>#</b>addObserver()</div><div><br></div><div>"[] delimiters are heavily array/collection/subscript-centric" (Chris)</div><br>> • Is the problem being addressed significant enough to warrant a change to Swift?<br><br>Yes. Sure, i love the entire idea behind this proposal, i think this will very beneficial for the language.<br><br>> • Does this proposal fit well with the feel and direction of Swift?<br><br>Yes.<br><br>> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br><br>Just some "hacks" in Objective-C.<br><br>> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br><br>I participated in the preliminary discussions re-read all variants of this proposal a lot of times.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Em dom, 14 de fev de 2016 às 20:35, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 14 Feb 2016, at 11:08, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> I ask again:<br>
>> What is wrong with arrow brackets?<br>
>><br>
>> var<lazy> foo<br>
><br>
> var<lazy, synchronized> foo: Dictionary<Int, Set<Optional<String>><br>
><br>
> So, two problems:<br>
><br>
> • Angle brackets already appear in var declarations for generic types; that means there are two different meanings for angle brackets in the same construct.<br>
><br>
> • When we eventually allow you to apply multiple behaviors to a single property, that will also mean that *commas* are used in both of those angle bracket constructs, but with different meanings (one means "chain these", the other means "fill these two slots").<br>
><br>
> These are not fatal errors, but they're also completely unforced—either `[]` or `{}` would not have this problem. So why choose the option that has the problem?<br>
<br>
Do we need braces and commas at all? It seems to me that you can just do:<br>
<br>
var lazy synchronized foo: Dictionary<Int, Set<Optional<String>>><br>
<br>
The name is always the one right before the colon, so this actually seems fine to me. If Xcode can colour them differently then it shouldn’t be hard to follow IMO. The order implies the order in which they are resolved where relevant, i.e- foo is mutable, then lazy, then synchronised.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>