Sent from my iPad
> On Jan 14, 2017, at 12:17 PM, Shawn Erickson via swift-evolution > <[email protected]> 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 > <[email protected]> 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 > <[email protected]>: > > > > 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 > > > _______________________________________________ > 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
