> On Jan 12, 2017, at 9:56 AM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Chris, thanks for this draft! > > May I suggest that the introduction mentions genericity on return type as > well? > > subscript<T>(_ index: Int) -> T > > (I have database rows in mind.)
Yeah, there’s no reason to restrict it to either just the index or element type. Slava > > Gwendal > >> Le 12 janv. 2017 à 18:53, Chris Eidhof via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> 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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
