> On Jan 11, 2017, at 10:53 AM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > >> >> On Jan 11, 2017, at 12:32 PM, Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>>>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution >>>>> <[email protected] <mailto:[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 >>>>> >>>>> <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. > > These topics do tend to come up together they are the two unnecessary > limitations subscripts have right now. I hope both make it into Swift 4. > I’m sure we’ll see a proposal after phase 2 opens up.
Another limitation is that subscripts cannot have default arguments. I don’t believe this even requires an evolution proposal, it’s a quirk of the implementation and can be fixed by cleaning up some duplicated code paths in SILGen. If anyone is interested in looking at this I can point you to the code in question. Slava > >> >> Thanks, -- E >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
