[swift-evolution] [Draft] Throwing Properties and Subscripts

[Morten Bek Ditlevsen]

Brent Royal-Gordon via swift-evolution <swift-evolution at ...> writes:

Hi Brent, Excellent work! That is an extremely well written proposal draft - and
I would love to see the proposal accepted.

Here are my 2 cents on the discussion about alternatives:

1. Omit throwing getters on properties:

Throwing getters were actual my original use case for something like this
language feature.

I think that your argument about symmetry is excellent. It would be a bad thing
to have to split a calculated property into a throwing getter method and a
throwing setter method in case the getter needs to be able to throw.

While a throwing calculated read only property could of course be remodelled as
a throwing method, I still think that it is up to the developer to decide how a
concept should be exposed in an API.

It would also conceptually be hard to grasp why a throwing setter could exist in
a calculated property while a throwing getter could not. I think this would make
the language harder to learn.

So I would definitely include both throwing getters and setters in your
proposal.

2. Require setters to be at least as throwing as getters

I agree with you that these should be completely independent. Again for the
reason that the interdependence would be a hard thing to grasp - and you have
already come up with use cases where it would be nice to have the independence.

3. Don't include willSet throws

I would personally leave this out of the proposal. In the Swift Programming
Language documentation 'willSet' and 'didSet' are described as 'Property
Observers'. To me, conceptually, this means that they can perform code based on
the observed value change, but they can only observe - not cause the setting to
not happen in the first place (if that is a fair view of throwing in willSet).

4. Include didSet throws

For the same reason as above I think that this should not be included.

5. Permit try on &foo itself, rather than the call using it

If we were not talking about an inout parameter, then I think 'try' on the
property getter itself should be allowed.

Today - if you have a throwing function that returns a value, then you can do:

someFunction(try throwingFunctionReturningAValue())

right?

Then you should be able to do the same with a property with a throwing getter:

someFunction(try throwingGetterProperty)

And then I guess that the same should be valid for an inout parameter. I don't
think that it makes the semantics less clear: No matter where the 'try' is
placed, you don't really know whether the throw will happen in the getter
(meaning that 'someFunction' and the setter will never be called) or in the
setter.

Just my 2 cents. Thanks again for a very thorough proposal draft!