Re: [boost] Interest in a "concepts lite" library?

On Apr 20, 2016, at 3:48 AM, Juan Pedro Bolivar Puente wrote:

Hi!

With concepts lite not getting into C++17, the need for library-based alternatives becomes more apparent. With this regard, the current Boost.ConceptCheck library is outdated, as it emulates an too old proposal for concepts, and it does not leverage more modern techniques (e.g. expression sfinae).

Eric Niebler proposed in his Range-V3 library a technique to simulate concept checking using C++11 [1]. I myself implemented a variation of such technique in the Atria library [2].

There is also the Tick library, which implements a form of concept emulation as well similiar to Eric Niebler's: https://github.com/pfultz2/Tick It supports gcc, clang, and MSVC, and has several already defined concept traits in the library(such as `is_container` or `is_iterator`). There is some more work that needs to be finished with the documentation. Once I finish work with the Fit library, I plan to finish up that library and submit it for formal review as well.

Atria's implementation differs in two ways with Range-V3 concepts:

- It is simpler, because it has no special support for refinements. A concept refines another just by checking the refined concept in the normal `requires` definition. The downside is that refinement information can not be used for dispatch.

The Tick library does support refinements and tag dispatching. It also provides `TICK_TRAIT_CHECK` which will traverse the refinements and report back which refinements failed. This is very useful because sometimes a concepts fails because of one its refinements(such `is_defaul_constructible`).

- It wants to be future-proof. Concepts defined with the `ABL_CONCEPT_SPEC` macro can be automatically upgraded to a Concepts Lite concept by redefining `ABL_CONCEPT` as `constexpr concept`.

Integral constants are more powerful and expressive than raw constexpr values.

There are few reasons though why Atria's implementation could not be directly included in Boost. I would like to work on a more formal proposal, but first I'd like to know if there is interest in it, and if there are any obvious concerns or questionmarks.

Just some notes, you will get better error reporting from the compiler using `typename std::enable_if<(...)>::type` instead of using template aliases such as `enable_if_t`. Most compilers don't have the infrastucture to trace template aliases(and I don't think they will anytime soon). This is why libraries have a `REQUIRES` macro instead. In addition for the Tick library, it proved benifecial as it allowed to handle boolean expression that are not dependent on the deduced template parameter, workaround constexpr bugs on MSVC and better handle function overloading. Also, the Tick library doesn't use the `valid_expr(f(x))` to check valid expressions, because if `f` returns void then it will fail substitution which means the trait is false even though it is a valid expression. Instead, it follows the suggestion by Jamboree of using a template `valid<...>` instead.

Thanks!

JP

[1] http://ericniebler.com/2013/11/23/concept-checking-in-c11/

[2] https://github.com/Ableton/atria/blob/master/src/atria/meta/concept.hpp https://github.com/Ableton/atria/blob/master/src/atria/meta/tst_concepts.cpp

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost