<div dir="ltr"><div>Hi, this is an alternative to your proposal, taking into account Chris' comments. <br></div><div><div><br></div><div>You could add precondition and postcondition on protocol methods and properties, for example:</div><div><br></div><div><div>protocol Configurable {</div><div> typealias Configuration</div><div><br></div><div> var configured: Bool {</div><div> @non-mutating get</div><div> set { precondition { configured == false } }</div><div> }</div><div><br></div><div> // unsure if this syntax is confusing, but it's consistent with get/set</div><div> func configure(configuration: Configuration) {</div><div> precondition { configured == false }</div><div> postcondition { configured == true }</div><div> }</div><div>}</div></div><div><br></div><div>The terms precondition, postcondition and @non-mutating are up for debate.</div><div><br></div>Importantly: conditions would have to be side-effect free and return a Bool. They would work just like an assertion, and output their condition on failure (ie. "Failed precondition: 'configured == false'!").</div><div><br></div><div>By side-effect free I mean:</div><div> * They would only be able to read properties (instance, or external) annotated as @non-mutating.</div><div> * They can run methods (instance, or external) marked as @non-mutating.</div><div> * Things like print(...) cannot be used, the program should be free to optimise these out.</div><div><br></div><div>This annotation may be used like @noescape. It would have to be verified by the compiler, it may be done automatically (iirc. LLVM has a similar annotation) but that could lower programmer awareness.</div><div><br></div><div>If it's possible to check the conditions at compile-time it would be great to do so, there's a proposal for compile time evaluation of expressions which may be relevant.</div><div><br></div><div>Another example, you could add assertMainThread() to a `get` precondition if assertMainThread is marked as side-effect free.</div><div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 8:48 AM, Paul Cantrell via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>> I know there’s talk on the core team of some more robust property decoration mechanism. Does this already fold into that effort?<br>
><br>
> Yes, I believe that this should be covered by that work, which is great. :-)<br>
<br>
</span>Then I’d plop it in as a use case (admittedly one of the less compelling ones) for that work, and drop this proposal.<br>
<br>
Is any of that work public yet? It sounds exciting. (Apologies if that question is a repeat; I confess that I have not followed every single message on this list.)<br>
<br>
Cheers, P<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div>