Topic: Let qualified lookup find associated friends in
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 11 Jun 2014 11:54:16 -0700
Raw View
--bcaec50161b599500104fb93f883
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 9:17 PM, David Krauss <potswa@gmail.com> wrote:
> A friend function which cannot be declared as a non-friend can only be
> found by ADL. Adding a nested-name-specifier to the function name disable=
s
> ADL and prevents the function from being found.
>
> Lookup is intricate to be sure, and I've written code that depends on
> namespace qualification disabling ADL. But, I can't imagine needing to
> remove ADL-only friends from the overload set.
>
> The case where it makes the biggest difference is in calling a function
> with explicit template arguments. The template argument list will only
> parse into a template-id if a template declaration is found for the
> potential template-name. This leaves the user with two options: declare a
> bogus template in the local namespace, or qualify the name. The first
> option is heinous, but the second doesn't work for friends, even if the
> library declares a bogus overload in its own namespace. Splitting the
> difference, the user can add a using declaration for the library's bogus
> template, but that still sucks.
>
> GCC simplifies this for users by not hiding friend function templates at
> all. Non-template friend functions and class templates are hidden, though=
,
> so as a bug it's suspiciously specific.
>
> What do folks think of letting ADL work its magic on namespace-qualified
> function names, within the given namespace? Although the problem sounds
> obscure, I suspect that the practice of qualifying a friend's name may be
> what's blocking GCC's conformance in this regard, which may be interprete=
d
> as an indication that the standard is at odds with industry practice.
>
> I'm CC'ing Daniel Kr=C3=BCgler for some opinion or confirmation regarding=
GCC's
> dialect... maybe it's just an ordinary pesky bug. Anyway, it would be nic=
e
> to see this convenience supported by the standard.
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 use
ADL *and* you know which namespace the function you're naming lives in?
That seems like a surprising set of circumstances.
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.
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<typename T> friend void f(A) { ... } };
int main() {
A a;
template f<int>(a);
}
--=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/.
--bcaec50161b599500104fb93f883
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 10, 2014 at 9:17 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">A friend function which cannot be declared a=
s a non-friend can only be found by ADL. Adding a nested-name-specifier to =
the function name disables ADL and prevents the function from being found.<=
br>
<br>
Lookup is intricate to be sure, and I've written code that depends on n=
amespace qualification disabling ADL. But, I can't imagine needing to r=
emove ADL-only friends from the overload set.<br>
<br>
The case where it makes the biggest difference is in calling a function wit=
h explicit template arguments. The template argument list will only parse i=
nto a template-id if a template declaration is found for the potential temp=
late-name. This leaves the user with two options: declare a bogus template =
in the local namespace, or qualify the name. The first option is heinous, b=
ut the second doesn't work for friends, even if the library declares a =
bogus overload in its own namespace. Splitting the difference, the user can=
add a using declaration for the library's bogus template, but that sti=
ll sucks.<br>
<br>
GCC simplifies this for users by not hiding friend function templates at al=
l. Non-template friend functions and class templates are hidden, though, so=
as a bug it's suspiciously specific.<br>
<br>
What do folks think of letting ADL work its magic on namespace-qualified fu=
nction names, within the given namespace? Although the problem sounds obscu=
re, I suspect that the practice of qualifying a friend's name may be wh=
at's blocking GCC's conformance in this regard, which may be interp=
reted as an indication that the standard is at odds with industry practice.=
<br>
<br>
I'm CC'ing Daniel Kr=C3=BCgler for some opinion or confirmation reg=
arding GCC's dialect... maybe it's just an ordinary pesky bug. Anyw=
ay, it would be nice to see this convenience supported by the standard.</bl=
ockquote>
<div><br></div><div>Can you give an example of a case where declaring the f=
unction in the surrounding namespace would be problematic, but where you st=
ill want to use ADL *and* you know which namespace the function you're =
naming lives in? That seems like a surprising set of circumstances.</div>
<div><br></div><div>If we choose convenience over consistency here, we make=
the language harder to learn, understand, and explain; C++ suffers from ha=
ving chosen convenience over consistency too many times already.</div><div>
<br></div><div>Perhaps instead we could allow 'template' to be atta=
ched to an unqualified template-id, then you could get the result you'r=
e looking for (and still support real ADL):</div><div><br></div><div>=C2=A0=
struct A { template<typename T> friend void f(A) { ... } };</div>
<div><br></div><div>=C2=A0 int main() {</div><div>=C2=A0 =C2=A0 A a;</div><=
div>=C2=A0 =C2=A0 template f<int>(a);</div><div>=C2=A0 }</div></div><=
/div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec50161b599500104fb93f883--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 12 Jun 2014 08:06:16 +0800
Raw View
--Apple-Mail=_6084CD22-D27E-4461-BBF6-09C8D19B6619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-12, at 2:54 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> Can you give an example of a case where declaring the function in the sur=
rounding namespace would be problematic, but where you still want to use AD=
L *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 namespac=
e declaration cannot exist. It also introduces template parameters of its o=
wn, one of which may be explicitly specified. It's not called 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.) Qualification with th=
e name of the enclosing (base) class, for a static member function, would b=
e redundant and likely confusing for the user.
ADL doesn't only peek into multiple namespaces, it's also a shortcut into t=
he many associated classes.
As an alternative, dispatcher functions are usually applicable when everyth=
ing is contained in a single library. However, those often require perfect =
forwarding, so some generality is lost. There is extra implementation and m=
aintenance cost too.
> If we choose convenience over consistency here, we make the language hard=
er to learn, understand, and explain; C++ suffers from having chosen conven=
ience over consistency too many times already.
Always permitting namespace qualification when the user already knows the n=
amespace is an improvement to consistency.
Allowing the user to restrict ADL to a particular known namespace or librar=
y (hierarchy of namespaces) would handily solve headaches such as name coll=
isions 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.
> Perhaps instead we could allow 'template' to be attached to an unqualifie=
d template-id, then you could get the result you're looking for (and still =
support real ADL):
>=20
> struct A { template<typename T> friend void f(A) { ... } };
>=20
> int main() {
> A a;
> template f<int>(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.
Perhaps require parens: (template f<int>)(a) or even (template f)<int>(a). =
I did find myself wishing for something like this.
--=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/.
--Apple-Mail=_6084CD22-D27E-4461-BBF6-09C8D19B6619
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–12, at 2:54 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>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 use ADL *and* you know which names=
pace the function you're naming lives in? That seems like a surprising set =
of circumstances.</div></div></div></div></blockquote><div><br></div><div>I=
have a function which depends on class template parameters, so a namespace=
declaration cannot exist. It also introduces template parameters of its ow=
n, one of which may be explicitly specified. It’s not called on an ob=
ject that would specify <font face=3D"Courier">this</font>, but there =
is a smart pointer to a derived class. (The identity of the derived class i=
s also important.) Qualification with the name of the enclosing (base) clas=
s, for a static member function, would be redundant and likely confusing fo=
r the user.</div><div><br></div><div>ADL doesn’t only peek into multi=
ple namespaces, it’s also a shortcut into the many associated classes=
..</div><div><br></div><div>As an alternative, dispatcher functions are usua=
lly applicable when everything is contained in a single library. However, t=
hose often require perfect forwarding, so some generality is lost. There is=
extra implementation and maintenance cost too.</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">
<div>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.</div></div></div></div></=
blockquote><div><br></div><div>Always permitting namespace qualification wh=
en the user already knows the namespace is an improvement to consistency.</=
div><div><br></div><div>Allowing the user to restrict ADL to a particular k=
nown namespace or library (hierarchy of namespaces) would handily solve hea=
daches such as name collisions between libraries.</div><div><br></div><div>=
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.</div><br><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><div>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):</div><div><br></div><div> struct A=
{ template<typename T> friend void f(A) { ... } };</div>
<div><br></div><div> int main() {</div><div> A a;</div><=
div> template f<int>(a);</div></div></div></div></blockq=
uote><div><br></div><div><font face=3D"Courier">template</font> as the firs=
t 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.</div></div><br><div>Perhaps require parens: <fo=
nt face=3D"Courier">(template f<int>)(a)</font> or even <font face=3D=
"Courier">(template f)<int>(a)</font>. I did find myself wishing for =
something like this.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_6084CD22-D27E-4461-BBF6-09C8D19B6619--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 11 Jun 2014 18:13:40 -0700
Raw View
--047d7bdc0aa479fdef04fb99453c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, 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@metafoo=
..co.uk> 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<typename T> friend void f(A) { ... } };
>
> int main() {
> A a;
> template f<int>(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<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?).
--=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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 11, 2014 at 5:06 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><di=
v class=3D""><div>On 2014=E2=80=9306=E2=80=9312, at 2:54 AM, Richard Smith =
<<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@meta=
foo.co.uk</a>> wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>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.</div>
</div></div></div></blockquote><div><br></div></div><div>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=A0<font face=3D"Courier">this</font>, 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.</di=
v>
<div><br></div><div>ADL doesn=E2=80=99t only peek into multiple namespaces,=
it=E2=80=99s also a shortcut into the many associated classes.</div><div><=
br></div><div>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.</div>
<div class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">
<div>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.</div></div></div></div>
</blockquote><div><br></div></div><div>Always permitting namespace qualific=
ation when the user already knows the namespace is an improvement to consis=
tency.</div><div><br></div><div>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.</div>
<div><br></div><div>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=
..</div></div></div></blockquote><div><br></div><div>I assume you mean Danie=
l =3D) You might also want to ask Jason Merrill.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word"><div><div class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div=
class=3D"gmail_extra">
<div class=3D"gmail_quote"><div>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):</div><div><br>
</div><div>=C2=A0 struct A { template<typename T> friend void f(A) { =
.... } };</div>
<div><br></div><div>=C2=A0 int main() {</div><div>=C2=A0 =C2=A0 A a;</div><=
div>=C2=A0 =C2=A0 template f<int>(a);</div></div></div></div></blockq=
uote><div><br></div></div><div><font face=3D"Courier">template</font> 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.</div>
</div></div></blockquote><div><br></div><div>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.</=
div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div>Perhaps require parens: <font face=3D"Courier">(template f<=
;int>)(a)</font> or even <font face=3D"Courier">(template f)<int>(=
a)</font>. I did find myself wishing for something like this.</div>
</div></blockquote><div><br></div><div>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?).</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bdc0aa479fdef04fb99453c--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 12 Jun 2014 09:18:43 +0800
Raw View
--Apple-Mail=_1E6B9AE3-DD11-4FCC-93D1-C1B8D4DD8B0B
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-12, at 9:13 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> I assume you mean Daniel =) You might also want to ask Jason Merrill.
Yes, and thanks.
>
> 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?).
Or just around the (template) keyword alone. There, that should enumerate all the possibilities :)
--
---
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 email 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-proposals/.
--Apple-Mail=_1E6B9AE3-DD11-4FCC-93D1-C1B8D4DD8B0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–12, at 9:13 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>I assume you mean Daniel =
=3D) You might also want to ask Jason Merrill.</div></div></div></div></blo=
ckquote><div><br></div>Yes, and thanks.</div><div><br><blockquote type=3D"c=
ite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
>
<div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div>Perhaps require parens: <font face=3D"Courier">(template f<=
;int>)(a)</font> or even <font face=3D"Courier">(template f)<int>(=
a)</font>. I did find myself wishing for something like this.</div>
</div></blockquote><div><br></div><div>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 expressi=
on-statement?).</div></div></div></div></blockquote><br></div><div>Or just =
around the <font face=3D"Courier">(template)</font> keyword alone. There, t=
hat should enumerate all the possibilities :)</div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_1E6B9AE3-DD11-4FCC-93D1-C1B8D4DD8B0B--
.