220 39626 <0b82cc47-9dd1-41f1-80b4-3e1469aaa9a9@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why are concepts restricted to namespace-scope? Date: Fri, 10 Aug 2018 00:24:57 -0700 (PDT) Lines: 418 Approved: news@gmane.org Message-ID: <0b82cc47-9dd1-41f1-80b4-3e1469aaa9a9@isocpp.org> References: <3825544b-b617-4a0e-a02d-a5041d989c15@isocpp.org> <93c917bb-1c8d-405d-80e9-4fe036af1a58@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_638_172201033.1533885897630" X-Trace: blaine.gmane.org 1533885773 24736 195.159.176.226 (10 Aug 2018 07:22:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2018 07:22:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBSX3WTNQKGQEYY5YOEA@isocpp.org Fri Aug 10 09:22:49 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fo1l3-0006M1-50 for gclcip-std-proposals@m.gmane.org; Fri, 10 Aug 2018 09:22:49 +0200 Original-Received: by mail-yw1-f72.google.com with SMTP id 133-v6sf11800613ywq.4 for ; Fri, 10 Aug 2018 00:25:00 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=hwo6aaVOQAmmkNh4UOGZA7o9cKwtWLh3LG+/YM2ECoY=; b=Z+HzW6H6Ee/dd7O7pwv511+FRbG1tphm9KswCtQWwi3PkoIy8VS8673ga7fuLp+GXB EnhnikeUbbZ/A0TvhQhSlzQkE3T/4U4LGjUKVa0T4QBrnCh3g4ys1TKC0koXqG71lHdW 0j+FFey1Dte2AHzr9FY9LQ4eIJAZLGO5v3BhnoOWlGlKGIOgYlgh3KwsmYEtANPHWCUU y3inW1Z9yFLOpD5Fhi4r4QvCmS3nrFI5kV3xXhPsiqJmlOPeM4AAsQ2Z9RKfyJAoiqY9 lSyoT0fosha+6+dsCxuxHbBiJNYg6Kqhah+/nU5aCzc4rWEKWcEvtgWHfRxXftnrC1Fo DN6w== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=hwo6aaVOQAmmkNh4UOGZA7o9cKwtWLh3LG+/YM2ECoY=; b=bKsCTVyG0FDwRJntVZWxnILn4AMOB0fcE9glackUtdlaPRvfnq15BR4M9qVSkYyKF7 QQjWuHwk2uJlI12wNRi9NkdOSwHLXGz/ELPpYBF+4tUAuQlLyKkyhOZBvAHEUd4xSx86 1prVSG+4XhE2QGskmToH/Yhnu2buXVC0bP0ywqmWn0kydcGbaaY0TcCaDr4umOTYDp2b DOwOewjVNboWXqS5o5nhPvhQlAvDz2dK6Oo55MYr/4bUV/n6FXkuYC+UjocoWId7DusB 1J0XsyfRpgkJTYJg9b8QWYTxc4Nc8xnF7c7Mf9IqqlPudqmk0HuIoNi+p75+1t1Z8ly0 2A3Q== 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=hwo6aaVOQAmmkNh4UOGZA7o9cKwtWLh3LG+/YM2ECoY=; b=kDE4ugkJdp6ClHX98FxcDzYtgR+D1cvkD6bHpvD7RcRSeMgN6T8I16L5BNt04k6ZGG 7hnsW6FOd82Q4DwB1yUwY+tYZJEhTnD2FKMRZh+8OB10cyZxPMgTPJNQroFfR8+nK8zD u9OesPuiyolnQFL1ZO5OU+bxiX9JNDBcS0QlpNXpIKotNq7oUg4TDymzBvS0/WtmvD7w uo2EcSIQLeYxeR+E5qmatk+U/BXbkabDIV0ww7gGnFilnuT4/hdftL3hY5zSaxZLqaEx DYzIRoui0p+MSwOAG5Z0HiZVWhuVy4QietkIAS9ByOUMnqeqrcNazaJouze80MtW0ywi 1quQ== X-Gm-Message-State: AOUpUlFZtH0DURWE0l5gA+YwSEEGY72w2w4fd+HVYg13nol9mfL73a7v SoiqfVwVQqxWsMkqiRcAAry3GA== X-Google-Smtp-Source: AA+uWPwv35Dt0TrFNl1am1LaYWTDn4++sLwfQ3nlR/D67oqRjcEAWHcKspOwTEyq/3s/jgZZpFtpJg== X-Received: by 2002:a25:8592:: with SMTP id x18-v6mr831192ybk.14.1533885899575; Fri, 10 Aug 2018 00:24:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:98cc:: with SMTP id p195-v6ls1690910ywg.2.gmail; Fri, 10 Aug 2018 00:24:58 -0700 (PDT) X-Received: by 2002:a0d:cb03:: with SMTP id n3-v6mr128014ywd.0.1533885898371; Fri, 10 Aug 2018 00:24:58 -0700 (PDT) In-Reply-To: <93c917bb-1c8d-405d-80e9-4fe036af1a58@isocpp.org> X-Original-Sender: inkwizytoryankes@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:39626 Archived-At: ------=_Part_638_172201033.1533885897630 Content-Type: multipart/alternative; boundary="----=_Part_639_388732386.1533885897631" ------=_Part_639_388732386.1533885897631 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, August 10, 2018 at 3:53:26 AM UTC+2, Arthur O'Dwyer wrote: > > On Wednesday, August 8, 2018 at 10:07:24 PM UTC-7, Justin Bassett wrote: >> >> I recently discovered that concepts must be defined at namespace scope.= =20 >> What is the reason for this? It seems like an arbitrary restriction to m= e,=20 >> when alias templates and variable templates can appear at class scope. >> >> This realization came from thinking about passing concepts as template= =20 >> parameters. It currently is not possible. Template parameters can't be= =20 >> concepts; they can only be template template (type) parameters, type=20 >> parameters, or value parameters. Wrapping the concept inside a struct=20 >> doesn't work as well, since the concept must be defined at namespace sco= pe. >> > > > Here's an example involving "member concept aliases" that I worked up the= =20 > other day on Slack: > > struct One { > template static void f(T); > template using concept concept_ =3D Red; > }; > struct Two { > template static void f(T); > template using concept concept_ =3D Blue; > }; > > template requires(Meta::template concept_) > void hooray(T t) { > return Meta::f(t); > } > > // ... > hooray(a_red_thing); > hooray(a_blue_thing); > > (It occurred to me that it is very convenient how neither `type` nor=20 > `value` is a reserved word in C++; and that it is corresponding unfortuna= te=20 > that `concept` *will* be a keyword. Notice the use of `concept_` above.) > > Casey Carter pointed out that *almost* the same effect can be achieved vi= a > > struct One { > template static void f(T); > }; > struct Two { > template static void f(T); > }; > > template requires requires (T t) { Meta::f(t); } > void hooray(T t) { > return Meta::f(t); > } > > // ... > hooray(a_red_thing); > hooray(a_blue_thing); > > The difference between the "concept" approach and the "anonymous=20 > requires-clause" approach has to do with subsumption rules. > Also, this smells a lot like smuggling a concept (e.g. `Red`) through a= =20 > function declaration (`One::f`), i.e., a sneaky technical workaround for = a=20 > missing feature in the language, analogous to how we used to have to=20 > smuggle variable templates through class templates (e.g. every type-trait= =20 > ever). > > If you're willing to forgo subsumption (which I personally am, AFAIK),=20 > then you can already achieve the goal of "member concepts" by simply=20 > rewriting all your concepts as plain old variable templates. To the exten= t=20 > that this doesn't work, it shows why we might want to add real member=20 > concepts and concept aliases. To the extent that this does work, it shows= =20 > why we don't technically need the `concept` keyword at all. > > struct One { > template static void f(T); > template static constexpr bool concept_ =3D Red; > }; > struct Two { > template static void f(T); > template static constexpr bool concept_ =3D Blue; > }; > > template requires Meta::template concept_ > void hooray(T t) { > return Meta::f(t); > } > > // ... > hooray(a_red_thing); > hooray(a_blue_thing); > > Here's the example, complete and compilable.=20 > > > =E2=80=93Arthur > Probably one thing that prevent this usage is that `concept_` concept isn't= =20 concept at least when `hooray` is parsed, you will need use prefix=20 `concept` to allow correct parsing of this code (same as you need use=20 `template` or `typename`). Another thing, why not use `some_concept`? Overall I think this was deliberately done to simplify whole design and=20 avion any unexpected iterations, It would be bad if concepts skyrocket to= =20 level of template metaprograming from beginning, AFAIK right now you can't= =20 do any arbitrary ordering of concepts that depends on metaprograming and=20 this is good thing. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/0b82cc47-9dd1-41f1-80b4-3e1469aaa9a9%40isocpp.or= g. ------=_Part_639_388732386.1533885897631 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, August 10, 2018 at 3:53:26 AM UTC+2, Ar= thur O'Dwyer wrote:
On Wednesday, August 8, 2018 at 10:07:24 PM UTC-7, Justin Bassett= wrote:
I recently = discovered that concepts must be defined at namespace scope. What is the re= ason for this? It seems like an arbitrary restriction to me, when alias tem= plates and variable templates can appear at class scope.

This realization came from thinking about passing concepts as template par= ameters. It currently is not possible. Template parameters can't be con= cepts; they can only be template template (type) parameters, type parameter= s, or value parameters. Wrapping the concept inside a struct doesn't wo= rk as well, since the concept must be defined at namespace scope.


Here's an example inv= olving "member concept aliases" that I worked up the other day on= Slack:

struct One {
=C2=A0 =C2=A0 = template<Red T>= static= void f= (T);
=C2=A0= =C2=A0 template<class T> using concept concept_ =3D Red<T>;
};
struct Two {
=C2=A0 =C2=A0 template<<= span style=3D"color:#606">Blue T> static void f(T);
=C2=A0 =C2=A0 template<= ;class = T> <= /span>using concept c= oncept_ =3D Blue<T= >;
};

template<class Meta, class T> requires(Meta::template concept_<T>)
void hooray(T t) {
=C2=A0 =C2=A0 return Meta::= f(t);
}

// ...
hooray<One>(a_red_thing);
hooray<Two>(a_blue_thing);

(It o= ccurred to me that it is very convenient how neither `type` nor `value` is = a reserved word in C++; and that it is corresponding unfortunate that `conc= ept` will be a keyword. Notice the use of `concept_` above.)

Casey Carter pointed out that almost the same effe= ct can be achieved via

struct One {=C2=A0 =C2=A0 template<Red T> static void f(T);
};
struct Two {
=C2=A0 =C2=A0 template<Blue T> static void f(T);
};

template<class Meta, class T> requires requires (T t) { Meta::f(t); }
void hooray(T t) {=C2=A0 =C2=A0 return Meta::f(t);
}

// ...
hooray<One>(a_red_thing<= span style=3D"color:#660">);
hooray<Two>(a_blu= e_thing);
<= br>
The difference between the "concept" approach= and the "anonymous requires-clause" approach has to do with subs= umption rules.
Also, this smells a lot like smuggling a concept (= e.g. `Red`) through a function declaration (`One::f`), i.e., a sneaky techn= ical workaround for a missing feature in the language, analogous to how we = used to have to smuggle variable templates through class templates (e.g. ev= ery type-trait ever).

If you're willing to for= go subsumption (which I personally am, AFAIK), then you can already achieve= the goal of "member concepts" by simply rewriting all your conce= pts as plain old variable templates. To the extent that this doesn't wo= rk, it shows why we might want to add real member concepts and concept alia= ses. To the extent that this does work, it shows why we don't technical= ly need the `concept` keyword at all.

struct One {
=C2=A0 =C2=A0 templat= e<Re= d T>= static= void f(T);
=C2=A0 =C2=A0 template<class T> static constexpr bool concept_ =3D Red<T>;
};
struct Two {
=C2=A0 =C2=A0 template= <Blue T>= static= void f(T);
=C2=A0 =C2=A0 templa= te<c= lass T&= gt; sta= tic con= stexpr = bool concept_ =3D Blue<T>;
};

template<class Meta, class T> requires Meta::template concept_= <T>
<= span style=3D"color:#008">void hooray(T t= ) {
=C2=A0 =C2=A0 = return = Meta::<= /span>f(t);
}

// ...
hooray&l= t;One&g= t;(a_red_thing);
hooray<Two>(a_blue_thing);

Here's the exam= ple, complete and compilable.

=E2=80=93Arthur<= /div>

Probably one thing that prevent= this usage is that `concept_` concept isn't concept at least when `hoo= ray` is parsed, you will need use prefix `concept` to allow correct parsing= of this code (same as you need use `template` or `typename`).
Another thing, why not use `some_concept<M, T>`?

Overall I think this was deliberately done t= o simplify whole design and avion any unexpected iterations, It would be ba= d if concepts skyrocket to level of template metaprograming from beginning,= AFAIK right now you can't do any arbitrary ordering of concepts that d= epends on metaprograming and this is good thing.

<= /div>

--
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/0b82cc47-9dd1-41f1-80b4-3e1469aaa9a9= %40isocpp.org.
------=_Part_639_388732386.1533885897631-- ------=_Part_638_172201033.1533885897630-- .