Ok, I've got a draft up as a gist: https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25
Before I submit it, could someone let me know if adding generics to subscripts would influence the ABI? ( still feel pretty clueless in that area). Thanks! On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution < [email protected]> wrote: > > > 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/b >> rowse/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 > > -- Chris Eidhof
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
