<div dir="ltr">I like the direction in which the proposal is moving, but I still have some concerns about syntax.<div><br><div><div>0.</div><div>Thinking about it, behaviours don&#39;t really need to be full-fledged types.</div><div>Brent gave examples, for me the most convincing one was that property `var x: lazy&lt;Int&gt;` doesn&#39;t really seem to be implementing protocol requirement `var x: Int { get }`.</div><div><br></div><div>1.</div><div>I love the suggested attribute-like syntax `@lazy var x: Int = 42`.</div><div>Brackets `var [lazy] x: Int` is a precedent syntax, and we want to avoid that if possible.</div><div>The position of @lazy also feels right, as well as motivation behind that.</div><div><br></div><div>2.</div><div>What&#39;s the point of `: Value {` part in behaviour declaration?</div><div>One of the purposes was disambiguating, which of the generic parameter we are&quot;.</div><div>If we don&#39;t want generic notation, then I see no reason for that.</div></div></div><div>So we have `public var behaviour lazy&lt;T&gt; { ... }`</div><div><br></div><div>3.</div><div>Just `initialValue` in the body seems odd. I suggest `attribute initialValue() -&gt; Value`, alternatives are welcome.</div><div><br></div><div>4.</div><div>How will the `var` part be used?</div><div>Are we going to allow `let` behaviours? We can always create a `let` behaviour by duplicating our initial behaviour and modifying as needed.</div><div>For example, `@lazy let x: Int` can be emulated with `@immutableLazy var x: Int`. In this case, we can replace the name by something better.</div><div>So, isn&#39;t it duplicating functionality? If we decide not to have `let` behaviours then we will just have to remove that `var` in declaration.</div><div>So we have `public behaviour lazy&lt;T&gt; { ... }` which is completely in line with structs and whatsnot.</div><div><br></div><div>Suggestions for &quot;future directions&quot;:</div><div><div><br></div><div>5.</div><div>We should be able to auto-derive types for variables with behaviours.</div><div>First of all, I don&#39;t see any reason why we can&#39;t: `@lazy var x = 42` is, obviously, the same as `@lazy var x: Int = 42`</div><div>Then, all existing variables can have their types deduced. If we can write `var x = 42` then why can&#39;t we write `@lazy var x = 42`?</div><div><br></div><div>6.</div><div>Member functions.</div>The ground for them is already prepared, actually.<div>I suggest the (obvious) syntax `x.@lazy.clear()` for calling functions of behaviour and `x.@lazy.storage` for accessing variables of behaviour.</div><div><br></div><div>7.</div><div>Access control of member functions.</div><div>Why not define access control modifiers on members of behaviour to mean the same as if they were applied to members of the enclosing type?</div><div>For example, `private var storage: Value?` would be accessible in the same file as enclosing type as `x.@lazy.storage`.</div></div><div><br></div><div><div>Regarding time issues, are we going to get another week for review? I support the proposal as a whole, but details are changing &quot;on the fly&quot;.</div></div></div>