[swift-evolution] [Idea] Generic subscripts

[Jacob Bandes-Storch]

+1 from me on this feature as well. It seems like a pretty obvious way in
which subscripts should be like functions, but aren't yet.

Would there be any need for setters and getters to have different generic
parameters? I suppose today there's only one place to specify the type of
the parameters, and the type of the value being retrieved/set, so it's a
moot point.

On Wed, Aug 3, 2016 at 6:33 AM Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160803/d1f0442e/attachment.html>