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

Subject: Re: [boost] Interest in a "concepts lite" library?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-20 09:32:00

> On Apr 20, 2016, at 3:48 AM, Juan Pedro Bolivar Puente <raskolnikov_at_[hidden]> 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