[swift-evolution] Generic Subscripts

[Dave Abrahams]

on Sun Jan 15 2017, John McCall <rjmccall-AT-apple.com> wrote:

>> On Jan 15, 2017, at 7:22 PM, Dave Abrahams <dabrahams at 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 at swift.org>
> wrote:
>>>> on Fri Jan 13 2017, John McCall <swift-evolution at 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.  

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.

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.

> 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