>>> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
