> On Jan 15, 2017, at 7:22 PM, Dave Abrahams <dabrah...@apple.com> 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 >>> <swift-evolution@swift.org> wrote: >>> on Fri Jan 13 2017, John McCall <swift-evolution@swift.org> 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. 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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
