[swift-evolution] Proposal: willGet

[Andrew Bennett]

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> 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
> 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/e4c0a1df/attachment.html>