Re: [boost] Is there BOOST_ENABLE_IF macro now?

Subject: Re: [boost] Is there BOOST_ENABLE_IF macro now?
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2013-08-20 13:27:52

On Tue, Aug 20, 2013 at 6:11 AM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

>
>> His argument is that the definition of concepts and their association
> with types is not rigid and formal anymore. It's just any constant boolean
> expression.
> It's not a bug, it's a feature.

It's not a "bug" or "feature," it's a design choice that makes it difficult
or impossible to add proper template definition checking in the future and
it also makes writing template definitions that use the concept more
difficult than the 0x approach. In ConceptsLite, rather than dealing with a
direct list of associated functions (including their parameter list and
explicit return type) and associated types, you instead have to deduce
everything from usage requirements if you are to actually check a template
definition or write any code that slightly deviates from the precisely
written usage specification. Programmers are used to writing functions
where their parameter types correspond to a type specification and 0x
concepts was extremely similar to that. You look at a concept definition
much like you would a type definition, see its functions and types, and you
are set. In terms of the compiler, it also means a direct route for doing
template definition checking since an archetype can be easily created from
a C++0x concept definition and checking a template definition is a matter
of the compiler just instantiating that template with the archetype.
ConceptsLite, on the other hand, deals with usage requirements in the
manner that we were forced to with SFINAE (simple expression validity and
direct compile-time constant expression checking). You now have to deduce
accepted use from the validity of various expressions. You also no longer
have automatically deduced associated types. Archetype generation also
becomes non-trivial making it no surprise that template definition checking
isn't tackled by ConceptsLite.

Keep in mind that C++0x concepts had this "informal" way to add concept
requirements, too. Again, that it existed wasn't a bug just like the
ConceptsLite approach isn't a "bug," but its usage is limited and you
wouldn't want to base all concepts around it, especially if you expect to
have properly checked template definitions. You use it when your concept
has a requirement other than an associated function or associated type that
is able to be checked at compile-time. In C++0x concepts it was the
std::True concept and took a bool as a parameter (as opposed to a type,
which is what most programmers are more familiar with regarding concepts).
When the bool is true, the concept is modeled. When the bool is false, the
concept is not modeled. This allows you to have any compile-time constant
expression as a concept requirement (just put a requires True<
your_constexpr_or_metafunction_check_here >; in a concept's definition). In
other words, if you really wanted to, you could exploit this functionality
to do complete ConceptsLite-style usage requirements by just taking
advantage of template overloads and specializations that utilize SFINAE and
referencing them in a std::True requirement.

Would anyone recommend that? No.

The problem is that this very general functionality acts pretty much as an
opaque barrier when it comes to proper archetype generation, and in turn,
makes it difficult to properly check template definitions. In ConceptsLite,
that barrier is less opaque, but still suffers from problems already talked
about both here and elsewhere. ConceptsLite "puts off" the possibility of
checking concept definitions to some time in the future, but if people
thought that the checking of definitions was too complicated in 0x, then I
find it extremely hard to believe that anything will come out of
ConceptsLite template definition checking, which is a more complicated
problem.

C++0x concepts was a complex feature, however it was extremely well thought
out and even had a working model for template definition checking. The
rational course of action once C++0x concepts was removed, given that it
was even in the working paper and had a working model, would have been to
simply scale things back. Rather than doing that, though, ConceptsLite
essentially throws everything out the window using the excuse of C++0x
concepts being too complicated as a means to push an entirely different
design, while certain others involved in C++0x concepts moved on to other
things.

For a much more sensible course of action than ConceptsLite, see Doug's
paper from earlier this year, which just scales back C++0x concepts without
sacrificing its most important parts:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3629.pdf

-- 
-Matt Calabrese