<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Finally caught up. :-) I like this latest version better than the two previous versions, but I kind of think that if behaviors can't emulate "lazy", we've failed. Nothing has a stronger motivation than that at this point in time; there's lots of cool things we <i class="">could</i> use behaviors for, but you can still write all of them with a wrapper type.</div><div class=""><br class=""></div><div class="">Deferred questions along that line of thought:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">- Can a behavior <i class="">optionally</i> have an initial value, and provide its own default otherwise?</div><div class="">- Can a behavior optionally have an initial value, and require phase-1 initialization in an instance initializer otherwise?</div><div class="">- Does a behavior with <i class="">no</i> initializer requirements <i class="">not</i> allow initial values?</div></blockquote><div class=""><br class=""></div><div class="">Other comments on the actual proposal:</div><div class=""><br class=""></div><div class="">- Is 'Self' the static type or the dynamic type of 'self'? That is, what does 'Self()' do in a class with subclasses?</div><div class=""><br class=""></div><div class="">- Someone else brought this up, but can I override behavior methods in a subclass with a new behavior? Can I invoke super's implementation of those behavior methods?</div><div class=""><br class=""></div><div class="">- Can I wrap a superclass property with a behavior? This version of the proposal doesn't have 'base', so I assume the answer is no, but that knocks out the <i class="">other</i> special-case language feature that was to be replaced by the general feature.</div><div class=""><br class=""></div><div class="">- I'm not sure why changing the storage in a public behavior is inherently fragile, unless they are public. I think it's more that behaviors are all inlined, so if the implementation changes there's no guarantee that existing users of the behavior are using the updated version. That means changes aren't breaking, just not guaranteed universal.</div><div class=""><br class=""></div><div class="">- Like many others I'm still not happy with the syntax—either the declaration syntax or the use syntax. I agree that it looks like a subscript and has nothing to do with other square brackets in the language…although there are only so many sigils. (Okay, I guess it's vaguely like capture lists.)</div><div class=""><br class=""></div><div class="">- I don't like that the name of the behavior shows up in the member access. I feel like the behavior of "Resettable" or "Observable" could be implemented by different behaviors, and I would want the freedom to resiliently change that while keeping the same public interface. Further down that direction lies "behavior protocols", though, which is <i class="">way</i> too much complexity for this…</div><div class=""><br class=""></div><div class="">- Nitpick: why are "willSet" and "didSet" mutating? (I know they are now, but that seems like the wrong interface once we have something more flexible.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I think that's all I have for now. </div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 22, 2016, at 16:33, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I've revised my proposal again based on more feedback. Syntax changes include:<br class=""><br class="">- adopting John McCall's declaration-follows-use syntax for behavior declarations. I think this looks nice and provides a reasonable framework for binding all the fiddly bits of a property, such as its type, name, and initializer.<br class="">- changing the proposed syntax for behavior member lookup to 'property.[behavior].member', as suggested by Tal Atlas and others. I think this has a nice symmetry with the `var [behavior]` declaration syntax, and doesn't occupy any new sigils. On the other had, Curt Clifton and others have raised the point that it could be mistaken for a subscript at a glance.<br class=""><br class="">To reduce the complexity of the initial feature review, I've also removed many of the bells and whistles from this initial version for separate consideration. For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized. This imposes some inconvenience on some use cases, but is an additive feature. I've also left behavior composition, extending behaviors, overloading behaviors, and name binding as future extensions. Joe Pamer raised some design and technical challenges around how type inference should work with behaviors too, which I think deserve focused discussion, so I'm sidestepping those issues by starting out saying properties with behaviors always need an explicit type. Here's the updated proposal:<br class=""><br class=""><a href="https://gist.github.com/jckarter/66ae8fb361c0d57b3227" class="">https://gist.github.com/jckarter/66ae8fb361c0d57b3227</a><br class=""><br class="">And for reference, previous iterations:<br class=""><br class="">https://gist.github.com/jckarter/50b838e7f036fe85eaa3<br class="">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3<br class=""><br class="">-Joe<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>