[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators

["dangelog at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.