[swift-evolution] [Idea] Generic subscripts
jtbandes at gmail.com
Wed Aug 3 11:07:19 CDT 2016
+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
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
> > 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
> > * 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
> > [SE-0132]: <
> > [SE-0131]: <
> > [anyhash-subscript]: <
> > [manifesto]: <
> > [discussion]: <
> > [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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution