[swift-evolution] Generic Subscripts

[John McCall]

> On Jan 15, 2017, at 8:32 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> 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.

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