220 11249 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Let qualified lookup find associated friends in named namespace Date: Wed, 11 Jun 2014 18:13:40 -0700 Lines: 197 Approved: news@gmane.org Message-ID: References: <3E7872EE-722E-43B2-BB2B-646D844B3DB0@gmail.com> <461800B5-6761-41F7-8158-A20AA3699DA0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc0aa479fdef04fb99453c X-Trace: ger.gmane.org 1402535632 31747 80.91.229.3 (12 Jun 2014 01:13:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Jun 2014 01:13:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBRP54OOAKGQEHJZGCTY@isocpp.org Thu Jun 12 03:13:45 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WutaJ-0003yb-J8 for gclcip-std-proposals@m.gmane.org; Thu, 12 Jun 2014 03:13:43 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id lj1sf2038253pab.5 for ; Wed, 11 Jun 2014 18:13:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=w+wdFA3lnkxEJOVUFRR7Yw3hVhcVt8E8yE+AZUP5xhE=; b=a/RHDFPTVNUL7OzBkFDWq/KoDhNd5RwpNoGKIPfdKXrLeJhYdwSEjyVfqlO2ZYZkD0 m4RJSazLor+qOp/qI2XOsZ63sypy2DgmtSzF/UHs/C+jjZN1jzbKog/Hln5OUk4dvCci 3iLp3dwDCFYAeIqAWJTvNyMFVBpcUT1OunOhUgnZhZynj5USafmdc3dZenc3QGrfr+8i WXVS+O/PvG6zHN5vTOoq8rDRsTa+bzlwrZjQH4VidHrpG7sMryR348cbCTrHkZ/BgjCZ j9bKxBrI6k34cvYwG6WRyWR/PplyYttxL5xnY3d6LGxtWI+COlkxu1Wjea0e6woJ8rlO fQUg== X-Gm-Message-State: ALoCoQk9fRclZMMeRpEy7Ppn3MnljCx5owFgpquHUTYzD8b4Xw9TQcbsIAkmia3eF5SannfScqRH X-Received: by 10.68.202.99 with SMTP id kh3mr9385399pbc.8.1402535622530; Wed, 11 Jun 2014 18:13:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.51.9 with SMTP id t9ls877207qga.72.gmail; Wed, 11 Jun 2014 18:13:41 -0700 (PDT) X-Received: by 10.52.121.19 with SMTP id lg19mr258386vdb.54.1402535621459; Wed, 11 Jun 2014 18:13:41 -0700 (PDT) Original-Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [2607:f8b0:400c:c03::233]) by mx.google.com with ESMTPS id dn9si14763619vdc.46.2014.06.11.18.13.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 18:13:41 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::233 as permitted sender) client-ip=2607:f8b0:400c:c03::233; Original-Received: by mail-vc0-f179.google.com with SMTP id id10so106085vcb.10 for ; Wed, 11 Jun 2014 18:13:41 -0700 (PDT) X-Received: by 10.58.229.101 with SMTP id sp5mr5873938vec.42.1402535621031; Wed, 11 Jun 2014 18:13:41 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.196.6 with HTTP; Wed, 11 Jun 2014 18:13:40 -0700 (PDT) In-Reply-To: <461800B5-6761-41F7-8158-A20AA3699DA0@gmail.com> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::233 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11249 Archived-At: --047d7bdc0aa479fdef04fb99453c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 11, 2014 at 5:06 PM, David Krauss wrote: > On 2014=E2=80=9306=E2=80=9312, at 2:54 AM, Richard Smith wrote: > > Can you give an example of a case where declaring the function in the > surrounding namespace would be problematic, but where you still want to u= se > ADL *and* you know which namespace the function you're naming lives in? > That seems like a surprising set of circumstances. > > > I have a function which depends on class template parameters, so a > namespace declaration cannot exist. It also introduces template parameter= s > of its own, one of which may be explicitly specified. It=E2=80=99s not ca= lled on an > object that would specify this, but there is a smart pointer to a derived > class. (The identity of the derived class is also important.) Qualificati= on > with the name of the enclosing (base) class, for a static member function= , > would be redundant and likely confusing for the user. > > ADL doesn=E2=80=99t only peek into multiple namespaces, it=E2=80=99s also= a shortcut into > the many associated classes. > > As an alternative, dispatcher functions are usually applicable when > everything is contained in a single library. However, those often require > perfect forwarding, so some generality is lost. There is extra > implementation and maintenance cost too. > > If we choose convenience over consistency here, we make the language > harder to learn, understand, and explain; C++ suffers from having chosen > convenience over consistency too many times already. > > > Always permitting namespace qualification when the user already knows the > namespace is an improvement to consistency. > > Allowing the user to restrict ADL to a particular known namespace or > library (hierarchy of namespaces) would handily solve headaches such as > name collisions between libraries. > > My use case is not the only motivation. I do hope that Dietmar weighs in > on whether this is something some GCC users actually need. > I assume you mean Daniel =3D) You might also want to ask Jason Merrill. Perhaps instead we could allow 'template' to be attached to an unqualified > template-id, then you could get the result you're looking for (and still > support real ADL): > > struct A { template friend void f(A) { ... } }; > > int main() { > A a; > template f(a); > > > template as the first token in the expression makes it look like a > template declaration. Local template declarations would be nice to have, > instead of polymorphic lambdas being such a special case. > Yes, the visual ambiguity here is a bit weird, but it'd look less weird if it weren't at the start of an expression. While I agree that local template declarations might make sense, I'm not convinced that local explicit instantiation declarations make sense, and this form of 'template' could never be followed by a '<' so that's the only thing it could conflict with. > Perhaps require parens: (template f)(a) or even (template f)(a)= .. > I did find myself wishing for something like this. > Parens would be a bit strange, since they're currently an idiomatic way of disabling ADL. Maybe there's another option (parens around the entire call, if it's at the start of an expression-statement?). --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7bdc0aa479fdef04fb99453c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 11, 2014 at 5:06 PM, David Krauss <potswa@gmail.com> = wrote:
On 2014=E2=80=9306=E2=80=9312, at 2:54 AM, Richard Smith = <richard@meta= foo.co.uk> wrote:

<= div class=3D"gmail_quote">
Can you give an example of a case where decl= aring the function in the surrounding namespace would be problematic, but w= here you still want to use ADL *and* you know which namespace the function = you're naming lives in? That seems like a surprising set of circumstanc= es.

I have a function = which depends on class template parameters, so a namespace declaration cann= ot exist. It also introduces template parameters of its own, one of which m= ay be explicitly specified. It=E2=80=99s not called on an object that would= specify=C2=A0this, but there is a smart poin= ter to a derived class. (The identity of the derived class is also importan= t.) Qualification with the name of the enclosing (base) class, for a static= member function, would be redundant and likely confusing for the user.

ADL doesn=E2=80=99t only peek into multiple namespaces,= it=E2=80=99s also a shortcut into the many associated classes.
<= br>
As an alternative, dispatcher functions are usually applicabl= e when everything is contained in a single library. However, those often re= quire perfect forwarding, so some generality is lost. There is extra implem= entation and maintenance cost too.

If we choose convenience over consistency here, we make the language h= arder to learn, understand, and explain; C++ suffers from having chosen con= venience over consistency too many times already.

Always permitting namespace qualific= ation when the user already knows the namespace is an improvement to consis= tency.

Allowing the user to restrict ADL to a part= icular known namespace or library (hierarchy of namespaces) would handily s= olve headaches such as name collisions between libraries.

My use case is not the only motivation. I do hope that = Dietmar weighs in on whether this is something some GCC users actually need= ..

I assume you mean Danie= l =3D) You might also want to ask Jason Merrill.

Perhaps instead we could allow 'templat= e' to be attached to an unqualified template-id, then you could get the= result you're looking for (and still support real ADL):

=C2=A0 struct A { template<typename T> friend void f(A) { = .... } };

=C2=A0 int main() {
=C2=A0 =C2=A0 A a;
<= div>=C2=A0 =C2=A0 template f<int>(a);

template as th= e first token in the expression makes it look like a template declaration. = Local template declarations would be nice to have, instead of polymorphic l= ambdas being such a special case.

Yes, the visual ambiguity here= is a bit weird, but it'd look less weird if it weren't at the star= t of an expression. While I agree that local template declarations might ma= ke sense, I'm not convinced that local explicit instantiation declarati= ons make sense, and this form of 'template' could never be followed= by a '<' so that's the only thing it could conflict with.
=C2=A0
Perhaps require parens: (template f<= ;int>)(a) or even (template f)<int>(= a). I did find myself wishing for something like this.

Parens would be a bit strange, since= they're currently an idiomatic way of disabling ADL. Maybe there's= another option (parens around the entire call, if it's at the start of= an expression-statement?).

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7bdc0aa479fdef04fb99453c-- .