Brent Royal-Gordon via swift-evolution <swift-evolution@...> 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! _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
