Topic: Rationale for why concepts can only be declared
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 20 Dec 2016 17:15:17 -0800
Raw View
--001a114420e8f808c6054420e313
Content-Type: text/plain; charset=UTF-8
On 20 December 2016 at 16:25, Anthony Hall <anthrond@gmail.com> wrote:
> Reading the current version of the Concepts TS, n4630, I see that both
> variable and function concepts are only allowed at namespace scope, but I
> don't see a reason given for this. I first stumbled upon this restriction
> while trying to write concepts in the private: section of a class, because
> they would be useful to me in writing the class itself, but they have no
> use in the class's interface or to outside client code.
>
> I also would find being able to write them in
> struct/class/function/lambade/basically any scope, as a way to factor out
> repetitive ad-hoc 'requires' constraints.
>
> Does anyone know the reasons that concepts have been explicitly limited to
> namespace scope?
>
Yes. It avoids the possibility of a dependent name resolving to a concept
name. This avoids a selection of nasty problems with dependent name lookup
and with partial ordering in the presence of dependent concepts.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DDAYw2ekp1LG7Jt%2BatYeWptzHQVihOkzFzZ2_7S5sDdw%40mail.gmail.com.
--001a114420e8f808c6054420e313
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 2=
0 December 2016 at 16:25, Anthony Hall <span dir=3D"ltr"><<a href=3D"mai=
lto:anthrond@gmail.com" target=3D"_blank">anthrond@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Reading the curr=
ent version of the Concepts TS,=C2=A0n4630, I see that both variable and fu=
nction concepts are only allowed at namespace scope, but I don't see a =
reason given for this.=C2=A0 I first stumbled upon this restriction while t=
rying to write concepts in the private: section of a class, because they wo=
uld be useful to me in writing the class itself, but they have no use in th=
e class's interface or to outside client code.<br><br>I also would find=
being able to write them in struct/class/function/lambade/<wbr>basically a=
ny scope, as a way to factor out repetitive ad-hoc 'requires' const=
raints.<div><br></div><div>Does anyone know the reasons that concepts have =
been explicitly limited to namespace scope?</div></div></blockquote><div><b=
r></div><div>Yes. It avoids the possibility of a dependent name resolving t=
o a concept name. This avoids a selection of nasty problems with dependent =
name lookup and with partial ordering in the presence of dependent concepts=
..</div></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DDAYw2ekp1LG7Jt%2BatYeWptzHQ=
VihOkzFzZ2_7S5sDdw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DDAY=
w2ekp1LG7Jt%2BatYeWptzHQVihOkzFzZ2_7S5sDdw%40mail.gmail.com</a>.<br />
--001a114420e8f808c6054420e313--
.
Author: Anthony Hall <anthrond@gmail.com>
Date: Tue, 20 Dec 2016 17:44:39 -0800 (PST)
Raw View
------=_Part_1037_1677295587.1482284679432
Content-Type: multipart/alternative;
boundary="----=_Part_1038_347402259.1482284679432"
------=_Part_1038_347402259.1482284679432
Content-Type: text/plain; charset=UTF-8
That's hard to argue against. I did wonder, right after posting, whether
it had something to do with name lookup.
I suppose 'detail'-style namespaces could be used as a workaround.
I'm curious if others have good workarounds they use for the equivalent of
private and locally scoped 'concepts'.
On Tuesday, December 20, 2016 at 8:15:40 PM UTC-5, Richard Smith wrote:
>
> On 20 December 2016 at 16:25, Anthony Hall <anth...@gmail.com
> <javascript:>> wrote:
>
>> Reading the current version of the Concepts TS, n4630, I see that both
>> variable and function concepts are only allowed at namespace scope, but I
>> don't see a reason given for this. I first stumbled upon this restriction
>> while trying to write concepts in the private: section of a class, because
>> they would be useful to me in writing the class itself, but they have no
>> use in the class's interface or to outside client code.
>>
>> I also would find being able to write them in
>> struct/class/function/lambade/basically any scope, as a way to factor out
>> repetitive ad-hoc 'requires' constraints.
>>
>> Does anyone know the reasons that concepts have been explicitly limited
>> to namespace scope?
>>
>
> Yes. It avoids the possibility of a dependent name resolving to a concept
> name. This avoids a selection of nasty problems with dependent name lookup
> and with partial ordering in the presence of dependent concepts.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ff1931-6ec1-4a44-9338-245051f34631%40isocpp.org.
------=_Part_1038_347402259.1482284679432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That's hard to argue against. =C2=A0I did wonder, righ=
t after posting, whether it had something to do with name lookup.<div><br><=
/div><div>I suppose 'detail'-style namespaces could be used as a wo=
rkaround.</div><div><br></div><div>I'm curious if others have good work=
arounds they use for the equivalent of private and locally scoped 'conc=
epts'.<br><br>On Tuesday, December 20, 2016 at 8:15:40 PM UTC-5, Richar=
d Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On 20 December 2016 at 16:25, Anthony Hall=
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"bHKqWRPGCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:';return true;" onclick=3D"this.href=3D'javascript:&#=
39;;return true;">anth...@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Reading the current version of the Concep=
ts TS,=C2=A0n4630, I see that both variable and function concepts are only =
allowed at namespace scope, but I don't see a reason given for this.=C2=
=A0 I first stumbled upon this restriction while trying to write concepts i=
n the private: section of a class, because they would be useful to me in wr=
iting the class itself, but they have no use in the class's interface o=
r to outside client code.<br><br>I also would find being able to write them=
in struct/class/function/lambade/<wbr>basically any scope, as a way to fac=
tor out repetitive ad-hoc 'requires' constraints.<div><br></div><di=
v>Does anyone know the reasons that concepts have been explicitly limited t=
o namespace scope?</div></div></blockquote><div><br></div><div>Yes. It avoi=
ds the possibility of a dependent name resolving to a concept name. This av=
oids a selection of nasty problems with dependent name lookup and with part=
ial ordering in the presence of dependent concepts.</div></div></div></div>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95ff1931-6ec1-4a44-9338-245051f34631%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95ff1931-6ec1-4a44-9338-245051f34631=
%40isocpp.org</a>.<br />
------=_Part_1038_347402259.1482284679432--
------=_Part_1037_1677295587.1482284679432--
.