Conversation
As long as we don't require a C++17 Standard Library base line we cannot assume that variable templates are available.
| namespace internal { | ||
| namespace sqlite_orm::internal { | ||
| template<class... Op> | ||
| std::unique_ptr<std::string> column_constraints<Op...>::default_value() const { |
There was a problem hiding this comment.
nit: later this can be translated to std::optional instead of std::unique. I used std::unique initially cause C++14 doesn't have std::optional
There was a problem hiding this comment.
I absolutely agree, however as I wrote in the PR description: "As long as we don't require a C++17 Standard Library base line we cannot assume that variable templates are available.". This is also true for all other C++17 Library facilities.
| using expression_type = Select; | ||
| using explicit_colrefs_tuple = ExplicitCols; | ||
| using hints_tuple = Hints; | ||
| static constexpr size_t explicit_colref_count = std::tuple_size<ExplicitCols>::value; |
There was a problem hiding this comment.
why do we come back from *_v to *::value approach here?
There was a problem hiding this comment.
Like I wrote in the PR description: "As long as we don't require a C++17 Standard Library base line we cannot assume that variable templates are available."
2 participants
Yet another PR with a bit of C++17 hygiene and a few improvements.
C++17:
namespace sqlite_orm { namespace internal {} }->namespace sqlite_orm::internal {}. This reduces code intendation, and makes it more obvious (to collaborators) what's part of the public namespace.Note: Because this changes a lot of white spacing it is best to hide whitespace for diff comparison.
Improvements:
std::get(). This function is really widely overloaded, so I consider it good practice in template code to qualify it if called with a tuple.Fixes:
limit()that was missed in PR sqlite_orm as a C++ named module #1336.