[swift-evolution] Proposal: willGet

[Chris Lattner]

On Dec 13, 2015, at 11:23 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 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() }
>    }

My opinion is that this is too narrow to be worth complicating the language for.  Property observers are simply sugar for computed getters, and we only did them in Swift 1 because they use-cases they covered were so common.  The hope is that we can eliminate them as a language concept and move them out to the standard library as well.

> 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?

Yes, I believe that this should be covered by that work, which is great. :-)

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

It depends on what you mean.  Swift does support “mutating getters”, but that means the getter cannot be used on a “let” value of that type.  If you mean side effects in general (e.g. calling print) then that would be fine (but probably still not a great idea for predictability :-)

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

No, this is sugar for computed properties.

> Does this preclude useful optimizations?

As stated, probably not.

> 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.

exactly! :-)

-Chris