Thanks for putting this together! I’m looking forward to seeing this make it into the language!
> On Jan 12, 2017, at 11:53 AM, Chris Eidhof via swift-evolution > <swift-evolution@swift.org> wrote: > > Ok, I've got a draft up as a gist: > https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 > <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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPhone > > On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution >>>>>> <swift-evolution@swift.org <mailto: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 >>>>>> >>>>>> <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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> >> >> -- >> Chris Eidhof >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
