Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no_case is a type in some make_primitives specializations, and a bool in others. #748

Open
BengtGustafsson opened this issue Dec 27, 2022 · 1 comment

Comments

@BengtGustafsson
Copy link

make_primitives<...>::no_case is a type in some make_primitives specializations, and a bool in others. This seems inconsistent, and I wonder if this is a bug:

boost/spirit/home/qi/string/lit.hpp:263:77: boost::spirit::qi::make_primitive::no_case is a type
boost/spirit/home/qi/char/char_class.hpp:98:27: boost::spirit::qi::make_primitive::no_case is a value
boost/spirit/home/qi/string/symbols.hpp:395:77: boost::spirit::qi::make_primitive::no_case is a type

The reason I'm asking is that I wrote a proposal P2669 to disallow such differences. When I presented it at the C++ standardization meeting some were worried that a lot of code would break, and that those breakages would not be bugs. To check the situation I made a Clang plugin which detects such differences. I then compiled quite a few repos (using vcpkg) and in Boost I encountered this only case where code would break if P2669 was standardized.

So I would be very interested in if this is indeed a bug or if you have good usage for the different kinds of the no_code name in different specializations. In the latter case it would be very interesting to get a statement regarding the complexities involved in fixing this if P2669 was standardized.

@djowel
Copy link
Member

djowel commented Dec 27, 2022

I think it is a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants