[swift-evolution] [Idea] Generic subscripts

[Matthew Johnson]

> On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm looking for consensus on, and a coalition for, including generic subscripts in Phase 1 of the Swift 4 design cycle.
> 
> The Need
> -------------
> 
> While prototyping my deferred [SE-0132][], I ran into trouble introducing `RangeExpression`, an abstraction to make the introduction of subrange features easier. Since RangeExpression is a protocol compatible with any index type, it has to have an associated type, and thus cannot be handled with an existential. I therefore had to add an overloaded subscript for each type, which partially defeated the purpose of having the protocol.
> 
> The lack of generic subscripts also forced a nasty workaround for a convenience subscript in [SE-0131][]. That proposal extends `Dictionary where Key == AnyHashable` (actually a hidden `_AnyHashableProtocol`, but that's a different story) with a convenience subscript which takes any `Hashable` type—except that, because generic subscripts are impossible, [it instead has to take a hidden `_Hashable` type instead][anyhash-subscript].
> 
> The generics manifesto suggests a third use case: [a subscript that can take any Collection of Index][manifesto].
> 
> The lack of this feature at the very least impacts binary compatibility directly. It also affects source compatibility in that features like subranges are designed around its absence, forcing workarounds which affect userspace. I see good reasons to do it now and few to delay.
> 
> Prior Art
> -----------
> 
> As mentioned, SE-0131 and SE-0132 would have benefited from this feature.
> 
> After a brief and mostly positive [discussion][], Harlan Haskins and Robert Widmann submitted a [pull request][] late in the Swift 3 cycle for generic and throwing subscripts. Personally, I think throwing subscripts are something we should include, but they're a separate issue and may not be appropriate for Phase 1; I would suggest severing the two parts of the proposal.
> 
> Next Steps
> ---------------
> 
> What I'd like to figure out at this point is:
> 
> * Who is interested in this feature?

I am interested in this feature, both for specific applications as well as because it lifts what feels like an arbitrary restriction.

One very common use case is in libraries that handle loosely typed data (JSON, Plist, etc).  

It’s also worth noting that they will allow us to simulate higher-rank functions more directly than we can today (with subscript as function application).

> 
> * Should it be severed from throwing subscripts?

Throwing subscripts are important, but don’t necessarily need to be introduced at the same time as generic subscripts.  However, the use case of libraries that handle loosely typed data will require both.  I believe that use case was the motivation for the proposal introduced by Harlan and Robert which is why both features were included.

> 
> * Does the core team agree that this is in Phase 1's scope?
> 
> * Do the people who might be able to implement this have any comments on it?
> 
> 
> 
> 	[SE-0132]: <https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md>
> 	[SE-0131]: <https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md#detailed-design>
> 	[anyhash-subscript]: <https://github.com/apple/swift/blob/e051c61c4d7eb33cdbb47b8ac04eae38203a61e6/stdlib/public/core/HashedCollectionsAnyHashableExtensions.swift.gyb#L147>
> 	[manifesto]: <https://github.com/apple/swift/blob/e3d8448bbdd059a55a6e72c24d07e994afaf5926/docs/GenericsManifesto.md#generic-subscripts>
> 	[discussion]: <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021450.html>
> 	[pull request]: <https://github.com/apple/swift-evolution/pull/372>
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution