I'm thinking I might have made a design mistake in the name of expediency back in v1.7.10 when I fixed the operator[] overloading problem.

For those who don't remember the "what and why" of it, the problem was that Row::operator[] was overloaded for several types of integer, for const char*, and I think even std::string. Since 0 can be converted to any of those types implicitly, GCC 3 rightly refused to compile any code saying something like this:

Row r; cout << r[0] << ....

GCC also gave ambiguous overload errors for code like this:

cout << r["fred"] ...

since "fred" is a pointer, and thus is convertible to an integer.

So, I removed all but operator[](size_type), added Row::lookup_by_name(const char*) to handle the string cases, and called it good.

But recently, it came to me that the integer overloads were probably the least useful of the bunch in real-world code. Intelligent database design doesn't make the client code dependent on the number or order of database columns. So, I wonder if it would have been better to keep operator[](const char*) instead.

Obviously I can't change it back until v1.8 or v2.0. Keeping that in mind, my question is, who would it bother if I changed these semantics? Who uses integer indexes into a Row object in real-world code?

I sure don't, but then, I use the SSQLS mechanism, and it hides the Row access within its internals. Several of the examples use Row::operator[](int), but they probably shouldn't, for the intelligent design reason I gave above.

I've attached a diff of the change you'd need to make to get the library itself and the examples to compile. Notice that class Row can no longer derive from the template const_subscript_container, since that demands that the subclass implement operator[](size_type). That's no doubt why I chose to keep the overload that I did. It's not a very good reason, but there it is.

I'd appreciate it if some of you would try this patch, and see how it affects your code. That will help me to decide if this item even makes it onto the Wishlist. Also, it would be nice to know what other items from template const_subscript_container we need to hoist up in to class Row in order to make real-world code continue to compile. I just hack-and-slashed it for this proof of concept.