Okay, I agree that throwing subscripts would be great to have. Likewise, generic(and maybe even throwing) properties could be useful. However, I think that for this proposal, it makes more sense to focus on just generic subscripts, and mention throwing subscripts as "future improvements"?
On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution < > swift-evolution@swift.org> wrote: > > [Forgot to CC swift-evolution the first time] > > When this came up last, it was seen as more so a bug in the current > implementation, rather than an explicit choice. There's no need for a > proposal, just a JIRA: https://bugs.swift.org/ > browse/SR-115?jql=text%20~%20%22Generic%20subscript%22 > > > It’s a nontrivial new user-facing feature with new syntax in the language, > so it’ll need a proposal. ‘twould be good for the proposal to link to the > JIRA ticket. > > I’ve only heard positive reactions toward this feature, and it’s something > that the standard library could make good use of. > > > +1, this would be clearly great to happen. > > -Chris > > > > I apologize for adding to this topic rather than starting a new one, but I > figure people interested in subscripts would be more likely to see my > question: > > Is there a good reason subscripts cannot throw? Right now you can create a > [safe: index] subscript to return an optional but you can't create one that > returns an unwrapped value or throws. > > > Throwing accessors are mostly straightforward, but there is a big > conceptual question: what happens if an accessor is called during error > propagation? For example: > > objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow() > > If the method throws, we currently still call the setter in order to > finish the access. If the setter can throw, then, we might end up with > multiple errors being thrown at the same time, which isn't good — the > language is put in the awkward position of having to invent an arbitrary > resolution mechanism. > > You might ask: why do we call the setter if an error is thrown? Well, > it's complicated. One reason is that the implementation technique we use > for generic access to subscripts and properties — accesses where we don't > know how the subscript/property is implemented — doesn't know how to > distinguish between *finishing* an access normally and *aborting* an access > abnormally. Some kinds of property/subscript implementation — ones > currently reserved for the standard library, but likely to be eventually > offered to users in some form — depend on doing extra work no matter how > the access is terminated, e.g. to release a buffer pointer. (In fact, in > general this applies even to get/set implementations, because even if we > decided not to call the setter when an error was thrown, we would at least > need to destroy the index argument that we were going to pass to the > setter.) In order to get consistent behavior between generic and > non-generic accesses, we've just generally been finishing the access all > the time. > > I think it would be possible to teach this generic mechanism the > difference between finishing and aborting an access, and thus to avoid > calling setters or otherwise doing arbitrary work that's allowed to throw > during an abort. However, we would first have to decide that those are > indeed the correct semantics and that setters should not be called after a > throw, and that would be a change in behavior. > > John. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Chris Eidhof
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
