Interest in a "concepts lite" library?
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]. 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. - 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`. 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. 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
I think Tick should be considered too https://github.com/pfultz2/Tick El mié., 20 de abril de 2016 14:05, Juan Pedro Bolivar Puente < raskolnikov@gnu.org> escribió:
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].
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.
- 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`.
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.
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
On Apr 20, 2016, at 3:48 AM, Juan Pedro Bolivar Puente <raskolnikov@gnu.org> 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
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.
- 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. 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. 3. something similar to the standard might help the standard committee in getting examples of practical use-cases. 3. integral-constant returning metafunctions can still be provided. 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".
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? 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. Cheers! JP
On Apr 20, 2016, at 9:16 AM, Juan Pedro Bolívar Puente <raskolnikov@gnu.org> 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
On 4/20/16 1: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).
I think such an effort is long overdue. The world needs a modern replacement for BCC. As mentioned in other posts, tick would also be a candidate. There might be others. I would like to see them considered/reviewed as a group in order to select the best candidate for boost. Robert Ramey
On Apr 20, 2016, at 9:56 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 4/20/16 1: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).
I think such an effort is long overdue. The world needs a modern replacement for BCC. As mentioned in other posts, tick would also be a candidate. There might be others. I would like to see them considered/reviewed as a group in order to select the best candidate for boost.
As this is all a volunteer effort, I think I would rather see better collaboration instead of competing.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think such an effort is long overdue. The world needs a modern replacement for BCC. As mentioned in other posts, tick would also be a candidate. There might be others. I would like to see them considered/reviewed as a group in order to select the best candidate for boost.
As this is all a volunteer effort, I think I would rather see better collaboration instead of competing.
Well, that's great too!
Robert Ramey
I think such an effort is long overdue. The world needs a modern replacement for BCC. As mentioned in other posts, tick would also be a candidate. There might be others. I would like to see them considered/reviewed as a group in order to select the best candidate for boost.
As this is all a volunteer effort, I think I would rather see better collaboration instead of competing.
Agreed. I have been reviewing your library and , bike-sheds about conventions and nomenclature aside, it seems like best candidate for an initial basis, because: 1) it is more feature complete and 2) provides better compiler support. Please let me know what you think is the remaining work to be done before a formal submission and I'll help with that. Cheers! JP
On Apr 21, 2016, at 2:03 AM, Juan Pedro Bolivar Puente <raskolnikov@gnu.org> wrote:
I think such an effort is long overdue. The world needs a modern replacement for BCC. As mentioned in other posts, tick would also be a candidate. There might be others. I would like to see them considered/reviewed as a group in order to select the best candidate for boost.
As this is all a volunteer effort, I think I would rather see better collaboration instead of competing.
Agreed. I have been reviewing your library and , bike-sheds about conventions and nomenclature aside, it seems like best candidate for an initial basis, because: 1) it is more feature complete and 2) provides better compiler support.
Please let me know what you think is the remaining work to be done before a formal submission and I'll help with that.
Most of the remaining work is: * finish documenting the traits that have been defined in traits/*.h * add and document so more traits - although some is provided, there is more that needs to be defined. Also, perhaps add some more traits from the STL2 like `is_regular` and so on. * add more introductory documentation perhaps explaining about type requirements and why they are needed. Also, adding a comparison between Boost.ConceptCheck and this library. * refine the reference documentation A lot more work is documentation oriented, unless you see somethings that can be improved. Just open an issue. Also, Robert Ramey has done a lot of writing about type requirements, I would like to see if I can utilize some of that for introductory documentation perhaps, or maybe Robert could help with modifying some of the writings to focus it on the Tick library with the purpose of having it included in the Tick documentation. Thanks, Paul
Cheers!
JP
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/22/16 10:09 AM, Paul Fultz II wrote:
Also, Robert Ramey has done a lot of writing about type requirements, I would like to see if I can utilize some of that for introductory documentation perhaps, or maybe Robert could help with modifying some of the writings to focus it on the Tick library with the purpose of having it included in the Tick documentation.
LOL - If I had nothing else to do I'd re-write huge swaths of Boost Documentation. The funny thing is, I don't consider myself all that great a writer. But I think I've done a pretty good job recently on things like the safe numerics library. At least it seems that those interested in criticizing it are not doing so due to misunderstanding about what it does and on one has criticized the documentation. My initiation on the subject was when I made the serialization library. The library was pretty popular so the documentation was subjected to much criticism and scrutiny. I had a really, really hard time figuring out how to do this. It was the subject of a long, contentious, threads about how to do it. I was subjected to the didactic style of boosts legendary "Mr. Personality" David Abrahams who sadly has moved to the dark side (working for Apple) to support his family. Without going into more details, you'll find it more pleasant to get suggestions from me. Basically I'm come down to a "formula" - almost a form based model. This I've detailed in the boost library incubator website under "requirements/documentation" and under "simple tools". I've banging on this particular drum for over a year now. I ranted on the subject at C++Now last year. I'm very gratified to find that it might be having some effect. I see submissions to the boost incubator are improved in this area. I see reviewers are more carefully scrutinizing documentation of submitted libraries and are insisting on improvements and that many of the criticisms seems better focused. I'd still like to do more here. One thing I'd still like to do is reconcile DOxygen with the documentation requirements as described in the incubator. I failed on my first attempt to do this, but now I'm thinking that it might be possible to do after all. Robert Ramey
participants (5)
-
Juan Pedro Bolivar Puente -
Juan Pedro Bolívar Puente
-
Manu Sánchez -
Paul Fultz II -
Robert Ramey