220 29967 <95ff1931-6ec1-4a44-9338-245051f34631@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Anthony Hall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Rationale for why concepts can only be declared at namespace scope Date: Tue, 20 Dec 2016 17:44:39 -0800 (PST) Lines: 100 Approved: news@gmane.org Message-ID: <95ff1931-6ec1-4a44-9338-245051f34631@isocpp.org> References: <1dd1345b-0bc7-4768-8afd-fd6f4f611d8a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1037_1677295587.1482284679432" X-Trace: blaine.gmane.org 1482284687 14337 195.159.176.226 (21 Dec 2016 01:44:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 01:44:47 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDQLJVXQ7EKBBCF547BAKGQEAACZ6KI@isocpp.org Wed Dec 21 02:44:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJVxS-00023z-6V for gclcip-std-proposals@m.gmane.org; Wed, 21 Dec 2016 02:44:42 +0100 Original-Received: by mail-pg0-f72.google.com with SMTP id b1sf341320826pgc.5 for ; Tue, 20 Dec 2016 17:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=28IUrRcb4Lyn6N9xMxVPcvQIreGwCJ9kct9PlQMUJo0=; b=AhnBMFact4LassFXML/qnUpiH+ZNP78HIkUUbEvHWspKfD16THw4e1IXaT+09Xu8P0 BIt8zYAqf0BfmTzL5aHw8DtYFymOzRto4CYHCtwIKv9/Fn5zwZbP4wZdDitEoIQjoNag PNlpjA3d0h66ayfusYcWz2WCxHDjnhAybUB3eRTKd2HdJzwXv84MCHwE8tRh371YUYwh vzh7h4Z4fZ1o1TAnQPMDoh54stXlKqax29gGBr/dzwv0raBp9BXYc+ssmsagTLYBeKfk MPJgP9m7jcSOJHtXMZXhD31b5d7j/uMBju69s9yfOAqq97ixUUgRb6fA/A4tQUE6vBtU nBHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=28IUrRcb4Lyn6N9xMxVPcvQIreGwCJ9kct9PlQMUJo0=; b=N0aWYc9bUVmwhPDuTIZaRhcZ1HopfFulvgZEgCet1zcwWdhhemw93Pq4yXSbJ9L+m2 H3rPOefDBttWzGx3HFUodF2HdUcFOsp5wzFTPdDfNf1vj8Pp2htGc+P8sCBHmAuVBYLN M2CC069iEOJ1ULeyDFrGVeDb2UVUnc3VzGFHM3sQZ1EuPvJ191Y+6rVyds5Aj8dmIulK Jor+EepF1U1lUDxj/ARBtQUMkX2jha1lTm9fXxyjoZhFLcXMr694xbnegMr2VycWrKlU WnVb3YVTnLojpyEX8dFFbC7gDM2bd/hhDYl3mveNDfZXtJwYjKcuntTuDsr0cHxfpRan qgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=28IUrRcb4Lyn6N9xMxVPcvQIreGwCJ9kct9PlQMUJo0=; b=Qn2qD3NZMRi48u87lEWm7WJ88OnJ3Es0XMs0W/P+PqltWvY9kiBrI/3rWE5K94lid4 ww3Ci9aaxtNUxEwm8dPzqQhbYtj/XZZKksmU015+JIAB5/3k17XR1UraExE1LT8pooAC w/FSJeSatPgjvsPtENdZ0rnwEwUQ0Xt0ZeYobNqpqvG4P15SI4LePZcggAOVf7xmoWAC ynj+aln7NO1ZNP9x2XgPo9xd/vjo0C8LohSK78aacgZ7cBdDbTwBI4c6NzZRyWa1Y2AO Uv3beCexW4Z1SDHiGNFOxt00E71vXuIWgkIgVBQ+2mSqIaTHQxtyUNEORC2WKdj7KGzx adsg== X-Gm-Message-State: AIkVDXLA8Ff2F6N3PinRpg1kT5/Mr3cSe/jNxWtqEGkhRN+E8jLq3Un6fUlfOiIXkzbPPA== X-Received: by 10.99.45.130 with SMTP id t124mr1220331pgt.64.1482284681154; Tue, 20 Dec 2016 17:44:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.26.102 with SMTP id u35ls17881422otu.4.gmail; Tue, 20 Dec 2016 17:44:40 -0800 (PST) X-Received: by 10.157.59.183 with SMTP id k52mr238018otc.4.1482284680163; Tue, 20 Dec 2016 17:44:40 -0800 (PST) In-Reply-To: X-Original-Sender: anthrond@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:29967 Archived-At: ------=_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 > 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
That's hard to argue against. =C2=A0I did wonder, righ= t after posting, whether it had something to do with name lookup.

<= /div>
I suppose 'detail'-style namespaces could be used as a wo= rkaround.

I'm curious if others have good work= arounds they use for the equivalent of private and locally scoped 'conc= epts'.

On Tuesday, December 20, 2016 at 8:15:40 PM UTC-5, Richar= d Smith wrote:
On 20 December 2016 at 16:25, Anthony Hall= <anth...@gmail.com> wrote:
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.

I also would find being able to write them= in struct/class/function/lambade/basically any scope, as a way to fac= tor out repetitive ad-hoc 'requires' constraints.

Does anyone know the reasons that concepts have been explicitly limited t= o namespace scope?

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.

--
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.
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-- ------=_Part_1037_1677295587.1482284679432-- .