<div dir="ltr">+1 for this proposal. I’m not clear on the syntax and need to take some time exploring it though. <div><br></div><div>As I read the code in the proposal, it once again blurred the lines for me between property and method. It often seems to me, at an intuitive / teaching level, a property is just semantic sugar for a particular method, combined with some secret sauce to manage the backing storage for the variable. </div><div><br></div><div>Someone (Doug?) mentioned getting some documentation out that would clarify the usage of property vs. method. I’d really like to see that for comparison against my own evolving heuristics. It would also be useful in discussing this proposal.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi everyone. Chris stole my thunder already—yeah, I've been working on a design for allowing properties to be extended with user-defined <strike>delegates^W</strike> behaviors. Here's a draft proposal that I'd like to open up for broader discussion. Thanks for taking a look!<div><br></div><div>-Joe</div><div><br></div><div><a href="https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3" target="_blank">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3</a></div><div><br></div></div></blockquote><div>… snip … </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><div style="font-size:14px;font-family:helvetica,arial,freesans,clean,sans-serif;line-height:1.6;padding:30px;background-color:rgb(255,255,255);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;margin:15px;outline:0px;border:0px"><h1 style="margin-right:0px;margin-bottom:10px;margin-left:0px;padding:0px;font-size:28px;margin-top:0px!important"><span style="color:rgb(51,51,51);font-size:18px;font-weight:normal">Defining behavior requirements using a protocol</span><br></h1><p style="margin:0px 0px 15px">It’s reasonable to ask why the behavior interface proposed here is ad-hoc rather than modeled as a formal protocol. It’s my feeling that a protocol would be too constraining:</p><ul style="padding-left:30px"><li>Different behaviors need the flexibility to require different sets of property attributes. Some kinds of property support initializers; some kinds of property have special accessors; some kinds of property support many different configurations. Allowing overloading (and adding new functionality via <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">extension</code>s and overloading) is important expressivity.</li><li>Different behaviors place different constraints on what containers are allowed to contain properties using the behavior, meaning that <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">subscript</code> needs the freedom to impose different generic constraints on its <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">varIn</code>/ <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">letIn</code> parameter for different behaviors.</li></ul></div></div></div></blockquote><div>Would a set of related protocols (given some suppositions above that we could identify categories of behaviors that have similar needs) be another option? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-size:14px;font-family:helvetica,arial,freesans,clean,sans-serif;line-height:1.6;padding:30px;background-color:rgb(255,255,255);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;margin:15px;outline:0px;border:0px"><p style="margin:0px 0px 15px">Instead of relying entirely on an informal protocol, we could add a new declaration to the language to declare a behavior, something like this:</p><pre style="margin-top:15px;margin-bottom:15px;background-color:rgb(248,248,248);border:1px solid rgb(204,204,204);font-size:13px;line-height:19px;overflow:auto;padding:6px 10px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px"><code style="margin:0px;padding:0px;border:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">behavior lazy<T> {
func lazy(...) -> Lazy { ... }
struct Lazy { var value: T; ... }
}</code></pre><h3 style="margin:20px 0px 10px;padding:0px;font-size:18px;color:rgb(51,51,51)"></h3></div></div></blockquote><div>I do like the idea of a behavior declaration. I find this to be relatively easy to model mentally. It fits with Swift’s general use of the type system to achieve both power and safety.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div style="font-size:14px;font-family:helvetica,arial,freesans,clean,sans-serif;line-height:1.6;padding:30px;background-color:rgb(255,255,255);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;margin:15px;outline:0px;border:0px"><p style="margin:0px 0px 15px">When do properties with behaviors get included in the memberwise initializer of structs or classes, if ever? Can properties with behaviors be initialized from <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;color:rgb(51,51,51)">init</code> rather than with inline initializers?</p></div></div></div></blockquote><div> There’s a separate discussion that mentioned allowing better control of which initializers are generated or synthesized for a given struct. There’s also been mention of a “derived” feature for adding conformance without needing to supply a separate implementation. This question seems related to me - it would be ideal if Swift had a coherent way to declare something that did not need definition because it can be generated by the compiler. In this case, to declare that a property is part of memberwise initialization. `behavior lazy<T>: memberwise {` ?</div><div><br></div><div>Observable behaviors would not want to be precluded from initialization, but would also not want to be fired on initialization - at least that’s my first reaction. Is that true for all behaviors - that they would not want to be fired if the property is set as part of the parent type’s initialization, but only on later changes?</div></div></div></div>