[swift-evolution] Generic Subscripts

[Thorsten Seitz]

> Am 14.01.2017 um 14:50 schrieb Gwendal Roué via swift-evolution <swift-evolution at swift.org>:
> 
>>>> 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.

This is not typesafe at all if the type does not depend on the argument. I'd prefer keys carrying the meta information of their respective database column keeping the whole API typesafe.

-Thorsten
 
> 
> 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/20170123/16458d62/attachment.html>