[swift-evolution] Generic Subscripts

Dave Abrahams dabrahams at apple.com
Sun Jan 15 19:32:37 CST 2017

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.


More information about the swift-evolution mailing list