I have very similar needs as well to allow for things to be generic on return type.
On Sat, Jan 14, 2017 at 5:50 AM 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. > > 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
