https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Giuseppe D'Angelo from comment #4) > 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.) I think that's fine for TS material. > 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. That seems better to me. > 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. Please don't! At least not in the next 9 days. We intend to vote out LFTSv3 at next week's meeting, there will be no more proposals for LFTS considered. And I don't want to derail the vote next week by having open proposals arriving at the last minute. Feel free to file a library issue though. If propagate_const ever gets proposed for inclusion in the standard then this should be taken into account.
