[swift-evolution] Generic Subscripts

Matthew Johnson matthew at anandabits.com
Sat Jan 14 12:55:34 CST 2017



Sent from my iPad

> On Jan 14, 2017, at 12:17 PM, Shawn Erickson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I have a throwing style data marshaling layer that uses throwing and return type inference to make the code clean and validation automatic with the optional ability to return default values if error or missing value, etc. This is for validating data coming from external sources into our app. Having generic return type and throwing subscripts would help make this code better for clients IMHO.
> 
> class Data {
> let number: Int
> let name: String
> }
> 
> ....
> data.number = try helper.value(forKey: "baz")
> data.name = try helper.value(forKey: "foo", otherwise: "bar")
> ....
> 
> .... or ideally something like ....
> 
> ....
> data.number = try helper["baz"]
> data.name = try helper["foo", otherwise: "bar"]
> ....
> 

This is exactly the kind of library I was mentioning.  There is a lot of demand for the ability to write these kinds of libraries for various different purposes.

> -Shawn
> 
> 
> On Sat, Jan 14, 2017 at 9:45 AM Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> I’m not sure, but I think that in this case the specific type of these values is determined at runtime.
> Then a safe approach would be separate string: String?, bool: Bool?, int: Int? computed properties, as it’s done in JSON parsers.
> 
> 
> 
> if let bookCount = row.value(named: "bookCount").int {
> 
>     ...
> 
> }
> 
> if let bookCount = row["bookCount"].int {
> 
>     ...
> 
> }
> 
> let bookCount = row.int("bookCount")!   // crash if database is corrupt
> 
> Additionally, this is an overall bad example of generics. Fields of database tables can only map to a limited set of static types in Swift, which are supported by database adapter.
> 
> 
> 
> 2017-01-14 16:50 GMT+03:00 Gwendal Roué via swift-evolution <swift-evolution at swift.org>:
> 
> 
> 
> 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
> 
> 
> swift-evolution at swift.org
> 
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> 
> swift-evolution mailing list
> 
> 
> swift-evolution at swift.org
> 
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170114/d0699bbc/attachment.html>


More information about the swift-evolution mailing list