Date: Thu, 30 Apr 2020 17:48:21 +0300
Herring, Davis wrote:
> > I'm not sure I see what additional problems this would create. At the
> > moment,
> >
> > inline char f()
> > {
> > return __func__[0];
> > }
> >
> > already causes an ODR violation if __func__[0] doesn't have the same
> > value in two translation units. Allowing people to instantiate templates
> > with __func__[0] doesn't seem to add much.
>
> I don't see how the ODR can be violated by two tokenwise-identical
> definitions that don't refer to any external entity. Perhaps an
> implementation might generate two different-valued weak symbols for
> "f::__func__", but so long as only one of them is used (by whichever weak
> definition of f is chosen), this seems to work correctly.
All compilers optimize the above to just "return 'f';", so if __func__[0]
varies, so does the result.
> > I'm not sure I see what additional problems this would create. At the
> > moment,
> >
> > inline char f()
> > {
> > return __func__[0];
> > }
> >
> > already causes an ODR violation if __func__[0] doesn't have the same
> > value in two translation units. Allowing people to instantiate templates
> > with __func__[0] doesn't seem to add much.
>
> I don't see how the ODR can be violated by two tokenwise-identical
> definitions that don't refer to any external entity. Perhaps an
> implementation might generate two different-valued weak symbols for
> "f::__func__", but so long as only one of them is used (by whichever weak
> definition of f is chosen), this seems to work correctly.
All compilers optimize the above to just "return 'f';", so if __func__[0]
varies, so does the result.
Received on 2020-04-30 09:51:40