Sent from my iPhone > On 14 Jan 2017, at 13:50, Gwendal Roué via swift-evolution > <[email protected]> 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.
Massive +1 to that > > Gwendal > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
