This is an interesting proposal. I have a couple of throwing `setSomething` methods in my code that could be expressed as throwing property setters. That said, I don't really mind them being methods. Methods having a verb in their names makes them fit well with `try` at the call site.
I also have a getter returning nil when it fails to retrieve its data, in which case an error becomes available in a separate `error` property. That would seem like an ideal case for a throwing getter... but I'm not too sure I'd use the feature in this case because if an error occurs in this part of the code I actually want to make that error become part of the state of the object, stored and available separately for use at a later point. Basically a non-interrupting error. So I find my current approach is actually quite fitting and I don't feel a throwing getter is something I really need. Perhaps this is something particular to my use case, but if I needed it to throw I'd use a method and it'd be perfectly fine. All that to say I'm pretty much neutral on this feature. To me it does not really add capabilities to the language, it just makes possible to do with properties certain things you can already do with methods, and I'm perfectly willing to use methods for things that can throw. But if properties could throw, especially the setter, I'd probably use the feature at some places. And whatever we end up with for properties, I feel subscripts should work the same. Subscripts are just parametrized properties. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
