> Am 23.01.2017 um 18:26 schrieb Gwendal Roué <gwendal.r...@gmail.com>: > >>>>>> 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. > > As long as your personal preference has no impact on return-type genericity > subscripts adoption, I'm fine with it :-)
No problem with that :-) -Thorsten > > Gwendal >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
