220 34739 <3a958923-c648-4d7e-a596-4f1fee6789c1@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Concepts are Adjectives, not Nouns Date: Tue, 10 Oct 2017 08:46:25 -0700 (PDT) Lines: 314 Approved: news@gmane.org Message-ID: <3a958923-c648-4d7e-a596-4f1fee6789c1@isocpp.org> References: <7e0b8951-a46a-470d-bb7c-1651e6c4d707@isocpp.org> <22229cfe-0d43-5c01-cef4-b6502de658c1@honermann.net> <43f95138-da2b-4f46-a6c7-2b4c05a2d277@isocpp.org> <66b299de-203d-b770-a6d8-7bcbb2a118fb@honermann.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3515_1782492104.1507650385467" X-Trace: blaine.gmane.org 1507650403 2981 195.159.176.226 (10 Oct 2017 15:46:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Oct 2017 15:46:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBUWW6PHAKGQEHSDXINI@isocpp.org Tue Oct 10 17:46:38 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1wjr-0007Yd-05 for gclcip-std-proposals@m.gmane.org; Tue, 10 Oct 2017 17:46:35 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id d12sf17677466vkf.1 for ; Tue, 10 Oct 2017 08:46:37 -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=8HPSEG7ZvjL70hn9oYPp9o9VYmGW7Fq76WjZTc9FPYc=; b=YclQOsQgmBhPbz9HTFux3aaUWYEpzZ9/0yGG0p5J5TLt+1O9QeNyiSzlYywyrTjb2a ROajakmTQT1IlPMRhagNmKul4lpdZqjsA39CyZH09KAMJuEdThNMuqWxd50yxAo792R4 39gNek2LCZlFVO0iq3D0RHX4wPnY0yDRp3K0nKVzDCFJDi4v4E7Md1T6dq0e9WOaMDZK lyp7tX3qs2NgsbZveypKJr6jzwPgOa3qNvCXosSIeUqLR0obSBX1U+Ym6XFkZgEkDJpl mCDZTsl/85evNLOuZU3W88qUsyy0xxvnoKmBME5635fYpMeNC7Eah73dN+u4lCKhsPq3 5u6A== 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=8HPSEG7ZvjL70hn9oYPp9o9VYmGW7Fq76WjZTc9FPYc=; b=FbBDRsj3zxaCjAzc95Mcop0CZjwtW88jXFuzX5ddypJD1b3OKT0ttQuNXCXnjcnG4C 4/IZejOY5KucW/btJrueyQx74dp/GEotgjIp0yKs3VS0FIa+wOb9RcbOrZatwsnAWUwY ERubP1b+Lr/odpSHVqP2gRmVZCmFwoXtklndtF19SU26+IHbJu/b8Wj+oisjTGsVAjEm OXstt+TaFx1beJmBGs8DlUWwRFowAaWU1wUGA1djptNnq6fvcrx5oFJcEZCiSJqxRQ4x xNy61uV6fwM0ce0Nwwt5pJDqGHTOrzJjidmY2pe9ioxccqJa+qJ+JYVy+LY+20ZB6Sbb H/xA== 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=8HPSEG7ZvjL70hn9oYPp9o9VYmGW7Fq76WjZTc9FPYc=; b=ERnI9tKyQRnQwg26AkqG7etP2wDYSBj/hlS+27/EI4evf8BxAEqrWWQ472CuemrqjO 6cxd5OL1003uRcbhHGo4upCmji9CM1qAh0IsRmHYPZImmk/T4Q5POL72s9wst9OwhxjV 5IzwRNmorIrGEqGd6kEdf2kYC/M4g5AyblvrIikXdo8d3JAyHUVYo4h6gS+HYTzi2peH 1dm8HnRqwLCR+qYoAqwmwpFOw0fzRIN2ZP4mA+cyyYMx7IU5XI73Ic6JJQziXsQztwAp uEaQnnkT9XMqSmyeBuCBLdz7VdGILQpvCb8rz1V41wIbsi1KU6JeXBFml0ZGE3OtgkV7 3stQ== X-Gm-Message-State: AMCzsaVHN5VLgV1wxydkp2RLR1T9k7mHR0in6BHD7Tf1M91m2F9+K3Fd v/U7U7hM8LZiQEkRHtSzE9fMwA== X-Google-Smtp-Source: AOwi7QDzw61D7WMn1+mzsgvTD7RSroVxEMCRTxHhNjrzCEInnbqzkC7Mr98qvix2jk6ogxhikfNsSw== X-Received: by 10.31.96.138 with SMTP id u132mr2894878vkb.115.1507650387517; Tue, 10 Oct 2017 08:46:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.153.129 with SMTP id b123ls2213657vke.20.gmail; Tue, 10 Oct 2017 08:46:26 -0700 (PDT) X-Received: by 10.31.178.146 with SMTP id b140mr687577vkf.24.1507650386127; Tue, 10 Oct 2017 08:46:26 -0700 (PDT) In-Reply-To: <66b299de-203d-b770-a6d8-7bcbb2a118fb@honermann.net> X-Original-Sender: florian.csdt@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:34739 Archived-At: ------=_Part_3515_1782492104.1507650385467 Content-Type: multipart/alternative; boundary="----=_Part_3516_1750946424.1507650385467" ------=_Part_3516_1750946424.1507650385467 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mardi 10 octobre 2017 17:19:26 UTC+2, Tom Honermann a =C3=A9crit : > > On 10/10/2017 05:51 AM, floria...@gmail.com wrote: > > Now the tricky part, the definition of a template (function or class: sam= e=20 > problem): > template struct bar; > In this case, it is ambiguous (probably not within the current proposed= =20 > grammar, but semantically). > T could be a type satisfying the concept Integer, or T could a non-type= =20 > parameter whose type satisfies Integer. > > > Not quite. > > If Integer is a concept, T is a type, non-type, or template parameter;=20 > which one depends on the kind of Integer's first template parameter (the= =20 > prototype parameter). > > If Integer is a type, then T is a non-type parameter. > With the current proposal, I agree with you, there is no compiler ambiguity= .. My point is not about how it is currently but how it should be. Let me rephrase my example: template concept Integer =3D /* T is an Integer type */; int i =3D 0; // i is a value of type int Integer j =3D 0; // j is also a value whose type satisfies the concept Inte= ger // In this case, both regular type and concepts behave the same // The following template (without concept) has non-type template parameter= : template struct foo; // The following template (with concept) **currently** has type template=20 parameter: template struct bar; // Now regular types and concepts behave differently with the current draft // How you would write a template with a non-type parameter whose type is= =20 constrained? // just mimic the syntax for non-type parameters: // template struct bar; // No, this is the same as before template requires Integer struct bar; // a bit=20 clumsy, not even sure it works with classes // Jakob's proposal: template struct bar; I hope now my little example shows you clearly the problem with the current= =20 grammar. And I can assure you that users will want both types and non-type= =20 template parameters for concepts on types. =20 > > My point of view about the proposal: I like the idea to put several=20 > constraint on the same type without requiring any "require" clause. I=20 > understand and approve, the need for disambiguation for the template=20 > parameters. > However, I would prefer an optional disambiguator. When it is not present= ,=20 > disambiguate arbitrarily (I would prefer to non-type parameters as it is= =20 > more consistent, but it would more useful to disambiguate to types in thi= s=20 > case). > I also think the ambiguity is present only in template parameters for now= .. > > > The use of disambiguation has a bit of a rocky history in C++. For=20 > example, the most-vexing parse, and 'typename' and 'template' keyword=20 > disambiguation. > Agreed, I would prefer never have to type 'template' and 'typename'=20 disambiguator. But here, it is a bit different. It is not about telling the compiler=20 something that it should know, but telling the compiler what choice we made= =20 among two perfectly valid choices. And that's also because we don't to repeat a lot of meaningless=20 disambiguator that we should have a default disambiguation policy (either= =20 the most common or the most consistent). =20 > > Tom.=20 > Hope I disambiguated the situation ;) Florian=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/3a958923-c648-4d7e-a596-4f1fee6789c1%40isocpp.or= g. ------=_Part_3516_1750946424.1507650385467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le mardi 10 octobre 2017 17:19:26 UTC+2, Tom Honer= mann a =C3=A9crit=C2=A0:
=20 =20 =20
On 10/10/2017 05:51 AM, floria...@gmail.com wrote:
Now the tricky part, the definition of a template (function or class: same problem):
template <Integer T> struct bar;
In this case, it is ambiguous (probably not within the current proposed grammar, but semantically).
T could be a type satisfying the concept Integer, or T could a non-type parameter whose type satisfies Integer.

Not quite.

If Integer is a concept, T is a type, non-type, or template parameter; which one depends on the kind of Integer's first templat= e parameter (the prototype parameter).

If Integer is a type, then T is a non-type parameter.

With the current proposal, I agree with you, there is no comp= iler ambiguity.
My point is not about how it is currently but how it sho= uld be.

Let me rephrase my example:
template <class T>
conc= ept Integer =3D /* T is an Integer type */;


int i =3D 0; =C2=A0 = =C2=A0 // = i is a value of type int
Integer j = =3D 0; // j is also a value whose type satisfies t= he concept Integer

// In this case, both regular type and concepts beha= ve the same


// The following template (without concept) has non-type template pa= rameter:template= <int I> struct foo;

// The following template (with concept) **currently** has type te= mplate parameter:
template <Integer I> struct bar;

// Now r= egular types and concepts behave differently with the current draft

= // How you would write a template with a non-type parameter whose type is c= onstrained?
// = just mimic the syntax for non-type parameters:
// template <Integer I> struct bar; // No, this is the same as before
template <auto I> requires Integer<decltype(I)> struct ba= r; // a bit clumsy, not even sure it works with classes

// Jakob'= ;s proposal:
template <Integer auto I> struct bar;

I hope now my l= ittle example shows you clearly the problem with the current grammar. And I= can assure you that users will want both types and non-type template param= eters for concepts on types.
=C2=A0

My point of view about the proposal: I like the idea to put several constraint on the same type without requiring any "require" clause. I understand and approve,= the need for disambiguation for the template parameters.
However, I would prefer an optional disambiguator. When it is not present, disambiguate arbitrarily (I would prefer to non-type parameters as it is more consistent, but it would more useful to disambiguate to types in this case).
I also think the ambiguity is present only in template parameters for now.

The use of disambiguation has a bit of a rocky history in C++.=C2=A0 Fo= r example, the most-vexing parse, and 'typename' and 'templat= e' keyword disambiguation.

Agreed, I would = prefer never have to type 'template' and 'typename' disambi= guator.
But here, it is a bit different. It is not about telling the com= piler something that it should know, but telling the compiler what choice w= e made among two perfectly valid choices.

And that's also becaus= e we don't to repeat a lot of meaningless disambiguator that we should = have a default disambiguation policy (either the most common or the most co= nsistent).
=C2=A0

Tom.

Hope I disambiguated the situation ;)

= Florian

--
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/3a958923-c648-4d7e-a596-4f1fee6789c1= %40isocpp.org.
------=_Part_3516_1750946424.1507650385467-- ------=_Part_3515_1782492104.1507650385467-- .