Sent from my iPhone
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution > <[email protected]> wrote: > > 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"? There's already a draft proposal covering throwing subscripts. You can mention it's existence, but I don't see a reason to say much. - Doug > > On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution > <[email protected]> wrote: >>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution >>>> <[email protected]> wrote: >>>> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution >>>> <[email protected]> wrote: >>>>>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution >>>>>> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > > -- > Chris Eidhof > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
