You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: