On Mon, Jun 8, 2020 at 4:34 PM Ville Voutilainen < [email protected]> wrote:
> On Tue, 9 Jun 2020 at 02:29, Richard Smith <[email protected]> > 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.
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
