[swift-evolution] Proposal: willGet

Paul Cantrell cantrell at pobox.com
Sun Dec 13 13:23:54 CST 2015


I can see several potential problems with this proposal, but it’s straightforward in concept, so I’m throwing it out for everyone to pick apart.


MOTIVATION

Siesta has several API calls that, like UIView hierarchies for example, should only be used from the main thread. (Yes, there are good design reasons for this. I’ll spare you the details.)

I have an assertMainThread() sanity check designed to catch developer thread usage mistakes at development time. I’m running through my public methods, adding calls where appropriate.

However, what I _really_ want to guard is not methods but properties. I’d need to add assertMainThread() in far fewer places, and would achieve better coverage, if I could attach it to property access.


PROPOSAL

Provide a “willGet” decorator for properties.

It cannot affect the returned value, and thus does not make the property a computed property. That means it can be attached even to let properties:

    let foo: String {
        willGet { assertMainThread() }
    }

Possible uses:

	access preconditions
	logging
	access counting / profiling


ALTERNATIVES

Of course I can do this:

    var foo: String {
        get {
            assertMainThread()
            return _foo
        }
        set {
            assertMainThread()
           _foo = newValue
        }
    }

    private var _foo: String

…but that gets messy when multiplied over all properties. Much nicer to do this:

    var foo: String {
        willGet { assertMainThread() }
        willSet { assertMainThread() }
    }


QUESTIONS / CRITIQUES

I know there’s talk on the core team of some more robust property decoration mechanism. Does this already fold into that effort?

Should willGet allow side effects? If so, does the existence of mutating getters in structs play out nonsensically?

Does this complicate the computed / non-computed property distinction for the compiler?

Does this preclude useful optimizations?

Does this open the door to horrible, horrible code? Wait, I know the answer to that one. It is a programming language feature … so yes, yes it does.

Cheers,

Paul


–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
https://innig.net • @inthehands • http://siestaframework.com/




More information about the swift-evolution mailing list