C++ Logo

SG10

Advanced search

Subject: Re: [isocpp-core] Feature-test macro for ADL calls with template arguments?
From: Ville Voutilainen (ville.voutilainen_at_[hidden])
Date: 2020-06-08 19:46:26


On Tue, 9 Jun 2020 at 03:38, Richard Smith <richardsmith_at_[hidden]> wrote:
>> >> It would seem
>> >> rather reasonable to allow programmers to detect when they can use the
>> >> new superior functionality.
>> > The SG10 policy has historically been to not include a feature test macro where there is a simple syntactic alternative that gets you the same functionality regardless of compiler support. As far as I'm aware, there is, in this case.
>>
>> I am yet to see a simple syntactic alternative in this thread. But
>> well, if this is not a reasonable feature-macro
>> addition for SG10, then we'll live without it. To me, it seems exactly
>> the kind of feature-detection use case a feature-testing
>> macro is good for.
>
>
> Can you give an example of how you'd imagine people using this? If we're expecting them to write
>
> #ifdef __cpp_something
> get<1>(qp);
> #else
> something_else(qp);
> #endif
>
> instead of, say,
>
> using adl::get;
> get<1>(qp);
>
> then it seems to me that the feature test macro doesn't give us syntactic simplicity either.

It gives syntactic simplicity at the call site. That matters a
thousand times more than what the library
gunk looks like. What I expect/imagine library writers doing is either

struct MyTupleLike {
...
  // the definition of get<> as a hidden friend goes here};
};

#ifndef __cpp_adl_template_call
// John's work-around goes here
#endif

or

struct MyTupleLike {
#ifdef __cpp_adl_template_call
  // the definition of get<> as a hidden friend goes here};
#endif
};

And *callers* do no using-declarations, and no ifdeffing. In the first
variant, they can use get<> in whichever
C++ version, but the library doesn't leak namespace-scope names when
we have the fix. In the second variant,
we just provide a less-featureful API rather than go nuts in the
library trying to cope with C++ name lookup.


SG10 list run by sg10-owner@lists.isocpp.org