[Bug c++/97710] New: Help with breaking change? cast point-to-member address in template parameter list

[Bug c++/97710] New: Help with breaking change? cast point-to-member address in template parameter list

[mick.pearson at wildblue dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

            Bug ID: 97710
           Summary: Help with breaking change? cast point-to-member
                    address in template parameter list
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mick.pearson at wildblue dot net
  Target Milestone: ---

GCC used to agree with MSVC in letting pointer-to-member addresses be cast
inside templates, i.e. compile time constants. Cygwin updated me to 10.2.0 and
this now produces an "error: 'reinterpret_cast' is not a constant expression"
diagnostic.

The Clang tracker laughed at a request I made in the past to enable this for
Clang. (Please reach consensus? https://bugs.llvm.org/show_bug.cgi?id=33708) I
doubt Microsoft will break this in future versions of MSVC since that's not
it's style, so I wonder if this is an oversight in GCC, and if not what
recourse exists. 

Thank you, maybe related:
https://patchwork.ozlabs.org/project/gcc/patch/or604puqhd.fsf@lxoliva.fsfla.org/

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-11-03
     Ever confirmed|0                           |1
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Please provide a stand-alone testcase.  The one from
https://bugs.llvm.org/show_bug.cgi?id=33708#c6 compiles with GCC (with
-std=c++11 and up).

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[mick.pearson at wildblue dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

--- Comment #2 from Mick P. <mick.pearson at wildblue dot net> ---
Sorry, I may have jumped to conclusion. I think there's a different problem
that goes like:

struct A{};
struct B:A{ int x; };
struct C:A{ T<A,(char A::*)&B::x> y; };

So T expects a pointer-to-member from A but will not cast (in template?) B's
member to an A type to satisfy the template.

The problem is with C++'s class template model it's very hard to define
pointer-to-member because they don't work like function templates, so you have
to define all of the parts of the pointer-to-member value first and satisfy
those in the parameter list, so it's easier to do casting logic inside the
template instance... and probably in my use case that's the only way to do it
for more technical reasons.

Anyway, this is a breaking-change if it's not understood. It worked in GCC 7
that I upgraded from.

These pointer-to-member values are second-class citizens in C++ since they're
really just simple short offsets (numbers) but they are a royal PITA to deal
with. We could use some tools where the standard comes up short.

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The above isn't self-contained either, T isn't defined.

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[mick.pearson at wildblue dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

--- Comment #4 from Mick P. <mick.pearson at wildblue dot net> ---
Sorry, here is an example diagnostic. The reason I couldn't follow it yesterday
is "make -j4" was causing the output to be scrambled.

>/home/Michael/collada/dom/include/dae/domAny.h:62:33: error: 'reinterpret_cast' is not a constant expression
>   62 |  DAEP::Value<0,xsAnyAttribute,_,(_::_)&_::_0> attrAny_et_cetera__value;
>      |                                 ^~~~~~~~~~~~
>/home/Michael/collada/dom/include/dae/domAny.h:62:33: error: '(ColladaDOM_3::DAEP::Elemental<ColladaDOM_3::domAny, 97, ColladaDOM_3::daeElement>::_)&ColladaDOM_3::domAny::_::_0' is not a valid template argument for type 'char ColladaDOM_3::domAny::*'
>/home/Michael/collada/dom/include/dae/domAny.h:62:33: note: because it is a member of 'ColladaDOM_3::domAny::_'

>"The above isn't self-contained either, T isn't defined."

I just meant to explain the underlying problem, since it's a different problem.

I can't get code highlighting to work with ``` or {{{. T would be something
like the following:

template<class A, int A::*> struct T{};

Maybe this link works? https://godbolt.org/z/fYEYGP

Output is similar:

template<class A, int A::*> struct T{};
struct A{};
struct B:A{ int x; };
struct C:A{ T<A,(char A::*)&B::x> y; };

I don't know, for casting purposes this seems logical, like something should
work, and had worked before.

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[mick.pearson at wildblue dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

--- Comment #5 from Mick P. <mick.pearson at wildblue dot net> ---
EDITED: In my example/link I changed the type from "int" to "char" by mistake,
but actually it shouldn't matter and using "int" produces even stranger results
that maybe should be investigated (using char for both produces the desired
diagnostic.)

Below is the "int" diagnostic, that looks erroneous in its own right
(nonsensical!)

><source>:4:17: error: '(int A::*)((0 == -1) ? ((long int)0) : (((long int)0) + 0))' is not a valid template argument for type 'int A::*'
><source>:4:17: note: it must be a pointer-to-member of the form '&X::Y'

[Bug c++/97710] Help with breaking change? cast pointer-to-member address in template parameter list

[mick.pearson at wildblue dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

--- Comment #6 from Mick P. <mick.pearson at wildblue dot net> ---
Desired scenario: https://godbolt.org/z/zKnh1s

template<class A, char A::*> struct T{};
struct A{};
struct B:A{ int x; };
struct C:A{ T<A,(char A::*)&B::x> y; };

Changing x to char yields the other diagnostic. PtoM types are fungible, I
don't know why casting should restrict them to concrete types this way, even if
the standard says so that's a straight-jacket just for strong type-safeness
sake.

[Bug c++/97710] diagnostic for invalid pointer-to-member (not function) as template argument with base to derived should be improved

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97710

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
           Keywords|                            |diagnostic
           Severity|normal                      |enhancement
            Summary|Help with breaking change?  |diagnostic for invalid
                   |cast pointer-to-member      |pointer-to-member (not
                   |address in template         |function) as template
                   |parameter list              |argument with base to
                   |                            |derived should be improved

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note EDG, GCC and clang all agree this is invalid C++98 - C++14. GCC rejects it
(when corrected the types to be all char) for C++17+ though (that is recorded
as PR 114620). I am not going to mark this as a dup of bug 114620 (because I
recorded that) but instead going to mark this as the diagnostic needing to be
improved.