Conversation
|
I am not sure what to do with the CI. Obviously all builds with cxxstd < 20 will fail. |
| /// | ||
| template <typename P> | ||
| struct PointNDConcept | ||
| concept PointNDConcept = requires(P point, typename P::template axis<0>::coord_t ft, typename P::template axis<P::num_dimensions - 1>::coord_t lt) |
There was a problem hiding this comment.
concept should be lower case?
| } | ||
| P point; | ||
| typename P::value_type; | ||
| requires std::regular<typename P::value_type>; |
There was a problem hiding this comment.
Better write with concept conjunctions?
concept PointNDConcept = std::regular<typename P::value_type> && requires(P point, typename...
Well, any build other than c++20 will fail, no? Since GIL cannot afford the luxury of https://github.com/boostorg/cobalt, I don't know any tricks other than the old-school |
|
Right, another option would be GIL v2. |
|
If we would be allowed to consider GIL up to Boost 1.90 as last GIL that supports mixture of older and newer compilers, and any GIL released after Boost 1.90 require >= C++20, that would be great! It would be an opportunity for more thorough refactoring and better experience for implementing new features. |
Is it our decision or shall we ask the community or a boost comity for advise? Would that involve a review process? I fully agree that much of the code of the library could be re-written in a simpler way with the new language feature (e.g. one-liner lambda instead of function object). For me, getting a meaningful compiler error message when using GIL instead of a gigantic stack of errors would be a huge improvement. Maybe I am wrong but I hope that the switch to C++20 concepts should help. In the meantime, I can try to keep the compatibility to see what that involves in term of added complexity and boilerplate. |
@sdebionne Good questions. Trying to learn about it on the Slack. |
319a6a2 to
8cc2a45
Compare
Description
Switch
Pointconcept from Boost.ConceptCheck to C++20 concepts.References
Discussed on
boost-gilcpplangTasklist