[swift-evolution] Proposal: willGet

[Etan Kissling]

Yay for Design by Contract. (https://www.eiffel.com/values/design-by-contract/introduction/ <https://www.eiffel.com/values/design-by-contract/introduction/>)

Don't forget Invariants, though - these have to hold globally, after each client called method has run to completion.

Would be very nice to get these into the language as it could allow for asserting certain correctness aspects statically.
Also nice to have the contracts show up in a public interface view as an addition to comments,
because these are typically much more precise when writing down a specification.

C#'s CodeContracts are unfortunately not often used, as a binary rewriter needs to be configured as an additional build step.
https://msdn.microsoft.com/en-us/library/dd264808%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396 <https://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx?f=255&MSPPError=-2147217396>

An additional problem with Contracts is that it's not a principle that's understood by everyone.
And to push these through a code base, everyone needs to be willing to apply them properly.


Etan




> On 13 Dec 2015, at 23:44, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi, this is an alternative to your proposal, taking into account Chris' comments.
> 
> You could add precondition and postcondition on protocol methods and properties, for example:
> 
> protocol Configurable {
>     typealias Configuration
> 
>     var configured: Bool {
>         @non-mutating get
>         set { precondition { configured == false } }
>     }
> 
>     // unsure if this syntax is confusing, but it's consistent with get/set
>     func configure(configuration: Configuration) {
>         precondition { configured == false }
>         postcondition { configured == true }
>     }
> }
> 
> The terms precondition, postcondition and @non-mutating are up for debate.
> 
> 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'!").
> 
> By side-effect free I mean:
>  * They would only be able to read properties (instance, or external) annotated as @non-mutating.
>  * They can run methods (instance, or external) marked as @non-mutating.
>  * Things like print(...) cannot be used, the program should be free to optimise these out.
> 
> 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.
> 
> 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.
> 
> Another example, you could add assertMainThread() to a `get` precondition if assertMainThread is marked as side-effect free.
> 
> 
> 
> 
> On Mon, Dec 14, 2015 at 8:48 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >> I know there’s talk on the core team of some more robust property decoration mechanism. Does this already fold into that effort?
> >
> > Yes, I believe that this should be covered by that work, which is great. :-)
> 
> Then I’d plop it in as a use case (admittedly one of the less compelling ones) for that work, and drop this proposal.
> 
> 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.)
> 
> Cheers, P
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/2db8a265/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/2db8a265/attachment.sig>