On Mon, Jun 8, 2020 at 4:34 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On Tue, 9 Jun 2020 at 02:29, Richard Smith <richardsmith@google.com> wrote:
>> I don't know what that "somewhere" would be, nor do I know why I'd
>> write a using-declaration for somewhere::get.
>
>
> Consider:
>
> // user.h
> struct get {};
>
> // user.cc
> #include "user.h"
> #include <QPair>
>
> That won't compile with your above approach. Unqualified lookup for 'get' finds the user's struct ::get, so ADL is not performed. Adding the using-declaration fixes the problem:

Sure, I understood what you meant before.

>
> // QPair
> namespace detail {
>   template<int> void get(...) = delete;
> }
> void whatever() {
>   using detail::get; // add this to fix the problem
>   QPair<What, Ever> qp;
>   get<1>(qp); // ::get not found by unqualified lookup, so ADL is performed now
> }
>
> If you have some default implementation of 'get' (such as a general unspecialized one), then you could 'using' that instead of using a placeholder one like detail::get.

Right; I have no intention of forcing my users or recommending that
anyone else forces their users
to write a using-declaration whenever they want to use a tuple-like
interface on their types, even if it
can sometimes theoretically clash with namespace-scope non-functions.

We have a language fix that makes hidden friend templates work with
ADL when template arguments are provided
for a call. We have work-arounds that don't come even close to
achieving the same functionality.

The way I see it is that we have an idiom (or "workaround" if you prefer) that works reliably and provides a superset of the functionality of P0846. (The language-level approach, by contrast, works in strictly fewer cases, and lacks the functionality of letting you choose to provide a custom fallback.) What functionality is missing from the 'using + ADL call' idiom that P0846 provides?

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.