https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
--- Comment #4 from Giuseppe D'Angelo <dangelog at gmail dot com> --- (In reply to Jonathan Wakely from comment #1) > (In reply to Giuseppe D'Angelo from comment #0) > > So. ideally, the conversion operators should be using C++20 constraints, but > > of course that's not possible. > > It's totally possible for C++20 mode. > > I don't know how much motivation anybody has to do anything about this > though. Sorry, what I meant is, of course there is interest at keeping this code to compile in pre-C++20 mode, and possibly have the same semantics no matter what's the language version used? Or is it acceptable to have such an "API break"? (E.g. stuff like `is_convertible_v<propagate_const<Derived *>, Base *>` changes value.) > And the spec seems wrong as well. The const overload should be constrained > for const T being convertible to const element_type*. Yes, that sounds like a defect to me. -- More in general, I think these operators are strangely defined. I'm not sure why they're not simply defined to be template <typename U> operator U *() requires (std::is_convertible_v<T, U *>); mut.mut. for the `const` version. The current definition also allows for pointer arithmetic (only if one uses a C++20 constraint, otherwise it doesn't work), which is something the original paper says it does NOT want to support. And the current definition allows for `delete`ing a propagate_const, which maybe is wanted, but in contradiction with the lack of support for pointer arithmetic. I guess I'll need to submit a paper.
