[swift-evolution] Proposal: Allow Getters and Setters to Throw

Brent Royal-Gordon brent at architechies.com
Tue Dec 8 17:41:07 CST 2015


If I may propose some answers to your questions, to spur discussion:

> In particular, how does this interact with inout?

When you use an `inout` parameter, notionally the getter is called before the function it’s passed to, and then the setter is called after. Either way, the error would be thrown at the call site and the callee would never even be aware that an error was possible. Basically, this just means that all the fancy optimizations where `swiftc` secretly elides the temporary variable used during `inout` have to be disabled, to ensure that any throw happens after the callee returns.

The inout parameter use will, of course, have to be marked with `try`. It would be nice if the grammar allowed you to mark only the `inout` parameter if that’s the semantic you wanted (not sure if `try &property` or `&try property` would be more appropriate for that); if for some reason that’s difficult to do, though, marking the entire call wouldn’t be a big deal.

> Is there a "rethrows" equivalent?

I don’t think so. What would it be rethrowing an error from? The value if it happened to be a closure? That seems a bit esoteric.

> What are the rules for overrides? (That last is probably very straightforward, but it ought to be written out explicitly.)

T -> U is a subtype of T throws -> U, right? So you could override a throwing accessor to make it non-throwing, but not the other way around.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list