<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="">Yay for <i class="">Design by Contract</i>. (<a href="https://www.eiffel.com/values/design-by-contract/introduction/" class="">https://www.eiffel.com/values/design-by-contract/introduction/</a>)</div><div class=""><br class=""></div><div class="">Don't forget Invariants, though - these have to hold globally, after each client called method has run to completion.</div><div class=""><br class=""></div><div class="">Would be very nice to get these into the language as it could allow for asserting certain correctness aspects statically.</div><div class="">Also nice to have the contracts show up in a public interface view as an addition to comments,</div><div class="">because these are typically much more precise when writing down a specification.</div><div class=""><br class=""></div><div class="">C#'s CodeContracts are unfortunately not often used, as a binary rewriter needs to be configured as an additional build step.</div><div class=""><a href="https://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx?f=255&MSPPError=-2147217396" class="">https://msdn.microsoft.com/en-us/library/dd264808%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396</a></div><div class=""><br class=""></div><div class="">An additional problem with Contracts is that it's not a principle that's understood by everyone.</div><div class="">And to push these through a code base, everyone needs to be willing to apply them properly.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Etan</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 13 Dec 2015, at 23:44, Andrew Bennett 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="">Hi, this is an alternative to your proposal, taking into account Chris' comments. <br class=""></div><div class=""><div class=""><br class=""></div><div class="">You could add precondition and postcondition on protocol methods and properties, for example:</div><div class=""><br class=""></div><div class=""><div class="">protocol Configurable {</div><div class=""> typealias Configuration</div><div class=""><br class=""></div><div class=""> var configured: Bool {</div><div class=""> @non-mutating get</div><div class=""> set { precondition { configured == false } }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> // unsure if this syntax is confusing, but it's consistent with get/set</div><div class=""> func configure(configuration: Configuration) {</div><div class=""> precondition { configured == false }</div><div class=""> postcondition { configured == true }</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">The terms precondition, postcondition and @non-mutating are up for debate.</div><div class=""><br class=""></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 class=""><br class=""></div><div class="">By side-effect free I mean:</div><div class=""> * They would only be able to read properties (instance, or external) annotated as @non-mutating.</div><div class=""> * They can run methods (instance, or external) marked as @non-mutating.</div><div class=""> * Things like print(...) cannot be used, the program should be free to optimise these out.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Another example, you could add assertMainThread() to a `get` precondition if assertMainThread is marked as side-effect free.</div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Dec 14, 2015 at 8:48 AM, Paul Cantrell via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
><br class="">
> Yes, I believe that this should be covered by that work, which is great. :-)<br class="">
<br class="">
</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 class="">
<br class="">
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 class="">
<br class="">
Cheers, P<br class="">
<div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=tTTJ5sn5y0uc3ODSZa-2BndLNwXCDS7T2cq5OlDDhG0Rv-2BDDpiVlQjQ1AAiUAHe3DluCJjlDcnqHp-2BMJ0hfQvnYgZjfqTLT4-2Bwe3TkLlWKdmRw2mK-2FGKqLP3-2BUTMRZXTI3WOhj1RvKXjUg3wTW6i4a6aBvQgleqUO-2BpcD66fZJFCVskLUYRhjwkpbBhASCbai9WBTNiJHDV2ijO3rUsJiFeDKBJTEQm4foxbrja-2FRqNCM-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>