[swift-evolution] Generic Subscripts

Shawn Erickson shawnce at gmail.com
Sat Jan 14 10:10:56 CST 2017


I have very similar needs as well to allow for things to be generic on
return type.

On Sat, Jan 14, 2017 at 5:50 AM Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

> Where generic subscripts are concerned, there are a couple of different
> things to express:
> - Generic parameter  (I can understand various co-ordinates for the data)
> - Generic return type (I can construct your preferred representation of
> the data)
> - Generic setter type (I can set the data using various compatible types):
>
>
> I think all of these should be expressed with a single generic signature
> on the subscript itself. The element type passed to the setter and returned
> from the getter should be the same IMO, otherwise it’s not clear how it
> will work.
>
>
> Yes.  It's quite important that any particular subscript reference is
> still a single consistent entity, even if generic; we would not want, say,
> a read-modify-write access to be able to somehow invoke the getter and
> setter at different generic arguments, or to traffic in different element
> types.
>
> 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.
>
>
> This is a consequence of your vision of subscript. If interesting, it is
> also limiting for no real purpose.
>
> As the developer of a Swift database library, I'd like to offer a better
> API than the following:
>
>     // Current state of affairs
>     let name: String = row.value(named: "name")
>     let bookCount: Int = row.value(named: "bookCount")
>     let hasBooks: Bool = row.value(named: "bookCount")
>
> Instead, I wish I could offer GRDB.swift would let its users write:
>
>     // With improved subscripts
>     let name: String = row["name"]
>     let bookCount: Int = row["bookCount"]
>     let hasBooks: Bool = row["bookCount"]
>
> And this requires genericity on return type.
>
> Gwendal
>
> _______________________________________________
>
> 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/20170114/c035396a/attachment.html>


More information about the swift-evolution mailing list