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

On Apr 20, 2016, at 9:16 AM, Juan Pedro Bolívar Puente wrote:

Hi Paul!

Thanks for taking a look! Your library makes a very interesting proposition. Comments follow:

...

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.

How did you get MSVC to work? Last time I tried to port my implementation I got stuck into a network of compiler crashes that I eventually assumed were due to the lack of proper expression SFINAE support and fundamentally unavoidable for such a library.

SFINAE is partly supported in MSVC 2015, and its enough for the Tick library. I believe Update 2 will improve support even more. The biggest problems I found with MSVC was constexpr support.

...

...

- 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.

An older version of my library was using integral constants too, but eventually I decided against it. Rationale:

1. this library wants to bring concepts to casual users of templates, not just metaprogrammers. constexpr functions might be easier to understand.

The syntax is the same for the end user. Furthermore, integral constants can make it more natural in many cases, which is better for newer users or those that are not familiar with metaprogramming.

2. constexpr functions would users to the library get the benefits of real concepts straight away, once they are there. Again, this is specially important for the intended audience, that would benefit a lot from better error messages, etc.

You don’t support refinements, so I don’t know what the benefit of “real” concepts would give you.

3. something similar to the standard might help the standard committee in getting examples of practical use-cases.

Even more so, using integral constant would help convince the committee to make concepts integral constants, instead.

3. integral-constant returning metafunctions can still be provided.

Which seems redundant to the user as `DefaultConstructible<T>()` can be either an integral constant or a constexpr bool.

In the library, the macro defines both `MyConcept` and `MyConcept_spec`, the later being usable with various metafunctions, giving that extra functionality to "power users”

Its not just for “power users”. Having a more natural syntax makes it more accessible to non-power users.

...

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.

That's interesting! Is that what allowed you to get rid of the MSVC crashes?

I don’t remember exactly what the errors were, I don’t remember a lot of crashes.

While in principle I am not fan of macros, specially when mixed in funny places of type declarations and signatures, a carefully designed REQUIRES macro may also provide a smooth C++-1N transition for concept clients...

...

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.

Atria concepts use the sintax `(f(x), may_be_void)` when `f` is allowed to return void, `may_be_void` being an arbitrary int constexpr. There are trade-offs to each and can't judge now what is better.

Which is easy to forget. Even Eric Niebler has forgotten to do this on one occasion(See https://github.com/ericniebler/range-v3/issues/29).

Cheers!

JP

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