> On Jan 15, 2017, at 8:32 PM, Dave Abrahams <[email protected]> wrote: > > > on Sun Jan 15 2017, John McCall <rjmccall-AT-apple.com> wrote: > >>> On Jan 15, 2017, at 7:22 PM, Dave Abrahams <[email protected]> wrote: >>> on Sun Jan 15 2017, John McCall <rjmccall-AT-apple.com> wrote: >>> >>>>> On Jan 14, 2017, at 6:41 PM, Dave Abrahams via swift-evolution >>>>> <[email protected]> >> wrote: >>>>> on Fri Jan 13 2017, John McCall <[email protected]> wrote: >> >>>>> >>>>>> I'm also not sure we'd ever want the element type to be inferred from >>>>>> context like this. Generic subscripts as I see it are about being >>>>>> generic over *indexes*, not somehow about presenting a polymorphic >>>>>> value. >>>>> >>>>> Actually I *would* want to be able to do that, though I admit it's the >>>>> 1% case (or less). >>>> >>>> Would you actually want the value type to be inferred, or you would >>>> just want it to be allowed to vary according to the index type? >>>> Because the former sounds like a huge usability issue. >>> >>> Both. Usability-wise, it's no worse than f<T>() -> T, which has its >>> (rare) uses today and doesn't cause a problem when it's not used. >> >> Well, I'm assuming you would like to be able to do things like call >> mutating methods on these things. > > Yes. That's already *possible* even without a default: > > func mutate<T, R>(_ x: inout T, applying body: (inout T)->R) -> R { > return body(&x) > } > > mutate(&thingWithGenericSubscript[3]) { > (a: inout X)->() in a.mutatingMethod() // deduce X > } > > Obviously this is awful. The default mentioned below helps eliminate > the awfulness.
Right. I described it as a usability problem, not an expressiveness barrier. :) > But not all subscripts are, or need to be, get/set, and even without the > default, the feature would be useful with get-only subscripts. True. And like I've said, it's possible that this isn't a big problem. John. > >> Maybe not in the use case you're thinking of, though? >> >>> Ideally I'd like to be able to guide deduction to pick a sensible >>> default for T when there's insufficient type context, but that's a >>> separable feature. >> >> Yes, defaulting would fix the usability problem. >> >> John. > > -- > -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
