You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Obviously though I don't want to break compatibility on the string conversion API on short notice. We'll need a smooth transition process.
Some ideas...
We could add a separate API versioning scheme to the string conversions. But it's tedious and ugly and I don't want to maintain a list of API versions. Also, there's a chance that we won't even need the scheme again in the future.
Or we could add optional string_traits fields for "these functions accept an encoding" and "these functions accept a source_location" and make them default to false. (If I can't make that work, they could be stand-alone constants). It feels like double specification though.
Or we could use nasty template trickery to suss out a conversion function's signature, and figure out which arguments to pass. There's some ad-hockery there (because there are several conversion functions to support), but we already do at least part of this work in pqxx::internal::args_f.
The new parameters would have to have defaults for compatibility. That's not always safe for encodings, but I think it's feasible to enforce this at compile time.
The text was updated successfully, but these errors were encountered:
Use decltype(pqxx::internal::args_f(pqxx::string_traits<T>::function)) to get a tuple representing the parameter types for a member function of pqxx::string_traits<T>.
Extract individual parameter types using std::tuple_element_type<index, params_tuple_type>.
Remove irrelevant qualifications using std::remove_cvref_t<param_type>.
Compare the result to an expected type using std::is_same<stripped_type, expected_type>.
We can then specialise code for different API versions using if constexpr.
For the 8.0 release it would be useful to extend the string conversion API with additional parameters:
std::source_location
into a conversion — see Usestd::source_location
in exceptions. #923.Obviously though I don't want to break compatibility on the string conversion API on short notice. We'll need a smooth transition process.
Some ideas...
string_traits
fields for "these functions accept an encoding" and "these functions accept asource_location
" and make them default tofalse
. (If I can't make that work, they could be stand-alone constants). It feels like double specification though.pqxx::internal::args_f
.The new parameters would have to have defaults for compatibility. That's not always safe for encodings, but I think it's feasible to enforce this at compile time.
The text was updated successfully, but these errors were encountered: