1. In my opinion it should not be called std.database, but let's say "std.dbc". This is because it looks like a wrapper over db clients. Moreover one may say it's almost impossible to make a common and effective interface which would work with all databases. e.g. someone on Wikipedia argues ODBC is obolete (check "ODBC today")
I agree that std.dbc would be more accurate, although I like std.database better because it is more recognizable. Another option could be std.database.client.
ODBC is less important now as there are fewer desktop applications that connect directly to databases. There is at least one example related to D, which is the ODBC driver for presto, which is used in Excel. Server side code is generally written using the underlying native client directly. However ODBC support is useful in that it represents a catch all that covers all databases for which a native client is not yet supported.
At least for the SQL databases, a standard interface is definitely achievable and I believe that it having it would allow D to get more traction as an application platform.
2. I'm not against such a functionality in Phobos. However your project seems to be a duplication of the DDBC project. And it was not proposed for inclusion so often.
There are a number of areas where this design is an improvement over DDBC: ease-of-use, better resource management (no scope, no GC), phobos compatibility, to name a few. There is a lot more that needs to be added to make it standards grade.
3. What I call a D Database API could be described as: - Database object - DbCollection object (equivalent to array) - ranges + std.algorithm
My design is indeed range based: stmt.range() returns a forward range proxy for the query results (the accessor name might change however).
Your engine project is interesting. I think there is common ground in the interfaces in the two projects, particularly in how the interface for the results might work. I will look more closely at the details to see what might be workable.
erik
