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