220 36571 article Path: news.gmane.org!.POSTED!not-for-mail From: Corentin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A plea for a consistent, terse and intuitive declaration syntax Date: Mon, 08 Jan 2018 17:03:16 +0000 Lines: 483 Approved: news@gmane.org Message-ID: References: <1abe0443-19be-4aff-8627-e87d1807b901@isocpp.org> <3c6d5694-b335-4aa1-983f-3218843a738e@isocpp.org> <16c7eb00-967f-49d4-8bd8-38900f4c5cae@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d53bcd70cd0056246c6bd" X-Trace: blaine.gmane.org 1515430903 24628 195.159.176.226 (8 Jan 2018 17:01:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 17:01:43 +0000 (UTC) Cc: mihailnajdenov@gmail.com, Jakob Riedle To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC72FQ6X7MLRBX6IZ3JAKGQE3OH6NFY@isocpp.org Mon Jan 08 18:01:38 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYand-0005Mi-Eo for gclcip-std-proposals@m.gmane.org; Mon, 08 Jan 2018 18:01:25 +0100 Original-Received: by mail-ot0-f199.google.com with SMTP id m43sf6510200otb.7 for ; Mon, 08 Jan 2018 09:03:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515431008; cv=pass; d=google.com; s=arc-20160816; b=rc5xtXWSGGglFaIjSuoonFrAQ2iSXAFdFWGJuso4+N7bm85SSdMmljP7lviZU2Yh/0 5ctHYGfU0PTJ/ys5y70VxWE2iDiA0J09WApyJz6GhZ9VvNfCJwOm9TRygxNAXNCjYVMY MF0BQUkjyjN7JGs/xpVShlnB5/FIkKjSuTwuJVYnmZq/ss4gV8Js3L+XG4/yw2e9qkiT 3MUD6pPZfpYcVYYaHEYmYRaA9k1UAJlCojTBHOTVq068vfv9CYtjLvyxaTt86K7pDKAl K8h+PQe9UJzKEXEuSvkdXlvisSPALpeNXCVDglikXQbVkPK9NYx7MpYFf9mJkLUNpnaf 7n4Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=k1e920KO59BNiXiIvaPe+2pM11b9Sos8A7JVn9tvspU=; b=IjqgC4Q2i8xA1ezfzrbQEGHJiT0blzM1aLFpsysumUKnh+M3pT9fI1OKWJAqRLbfh0 vikeZPG53OE8V0Zg3gwIQvv6K4YKPIXe8cAGQ+Cd3vmGoVKiGev/8J2EXzonNUMMZAq4 85xSILoz8sn3qpMXnuKc8JbBmLietfdLLbCuTx7vRshi7HdPY4gGoOXPwgfU/KMb8Akx 6xAcod1rFQuN/ZAQbt38PHYaOltH9zQqlJjJIRKA1Ifn4uy9zbC1f4yynJytoiTho5WO xpkrMf+GxayxdADNqW6M1MCb7oltveKr7XzTnvE3fOhb/oey4bq6+kRn8q8HRMx9XVEW Q1/Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=efow3zEY; spf=pass (google.com: domain of corentin.jabot@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=corentin.jabot@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=k1e920KO59BNiXiIvaPe+2pM11b9Sos8A7JVn9tvspU=; b=0aW2/cd/IOl5fR5C7SIR9VuSbkczVFLI8IDobHQmKF/mB+inrAkz1W2qzGb3017mBj N2Lo42mmttatBNJokKn205V3y2vTok6KsQ+A6VNtLw62tOOubCYFOqPaqG0i37HfqkYj 4VnHeuXjGDNZ22FnPSpr+19fwkOVa6zXfss+RtJNizt2OsveJtP3WaAR0WPANMSLtbMx 2ZZ9MIyNp746jPLzyN+TgcVp7KC51GJrTcX3OItWPuoq/gbj0+N9qyS3YgAzsj1oPFgz 4fqcvb/ZCeno6S57LwMsg1mj8Ien64ttXI1vsrI7zNtoOSfncM40i6uwx7c09RQyKz8N ptow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=k1e920KO59BNiXiIvaPe+2pM11b9Sos8A7JVn9tvspU=; b=MHQGtRSscKnUYLFZszpHOms1nzfFnk7s9i8klEgf+WhKHah17ArweiRpW2HOJ/5ZTl NmSgbbkbFk/7tmsihMbQg1Fi9l7Ip0G3t2iOyJLnGCq8/JyqtoRbMfYplAoFPyxCdZYx 8TEP9CrJOuvy5MP95+HmXIY3+vEZVExCLGo6nYnQ22h++3gNkIhp/tpr6DElv6caYE0/ NLAB8qFUukFXbCXdrgLmiu9bltAcZo9ZjQFWRqIv+pK/NbdY0H0I1EMuStepqzJJjBHE GSrDht4ZyVXry0VjVBQZfu8HOlWfmEk23s1U1hj9ApFmEV3vIKhwDH54iVegrhlhOKhy h+bw== X-Gm-Message-State: AKwxytdZZPrcEftDo7J8UlkEQJ+GfG8vpVT8xiKzRx8TXH+3eReXrnWV qBcBlfRjuUlLRZ7495Ct1af2mA== X-Google-Smtp-Source: ACJfBoso0EiAv9aB+NSQWOWEdl4R32/76e5uZCWyVE79VDm1GyitXjXdG7s9L9WIPGE+Nmds4KSXNg== X-Received: by 10.157.52.210 with SMTP id t18mr6425755otd.82.1515431008370; Mon, 08 Jan 2018 09:03:28 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.229.136 with SMTP id c130ls142033oih.1.gmail; Mon, 08 Jan 2018 09:03:27 -0800 (PST) X-Received: by 10.202.66.8 with SMTP id p8mr5815554oia.65.1515431007486; Mon, 08 Jan 2018 09:03:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515431007; cv=none; d=google.com; s=arc-20160816; b=YJOJRV+8Dp+OmEfCEJotMMW913uomPOVT4r3eDD0KIA2ETM6TvaY3tFTmy5X6GYFRx 5Hf4WJiuh0HtKEHCL56v7fGbt2BIOWTHw736UvOl9Db1eFGCA3Gks1v8Hsaim6hkmQBj bogHY0GLmRcI8+uL+5h8vdXTcHkMuoTLftTswhWbO7jg+CsVm5twuje0LffpqNqwpjPq lS1RVlRqgjFWRDQQRAjU6BAdZ2H/SMA2HmbZjMq/N2upB8HaSwpfUtx4ZTctRPwipABr wlAnLjqFnkMr4PfHbUOzUWMJeYn5Gm4iWlfc5ICIET2qGkmFoYn/sKziQKLCGSTx2KsZ q2Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature:arc-authentication-results; bh=wgDrlFsnR7Uv0whfOfheVZdDrsNiQsiZQJPuMCYIvGo=; b=XmOLJMK4bDCyY9MkM2r45CcHx+zsCjbe082Y6A8bbUkdt3cV2o1TJed5vZa5qMgBzk r+VDU8dnjNampoShEfRGKpbxQGslzgW7f737LegTJ613FUd0DPXtVoGlVPDdb3Rww5gc R+ezi4ENOxNbhZBXrD095GgzorbsOM5bAAHYCUKZckqGOyzSxaHZQr+GAAlXIK6MfRH3 a7H6YFBThttoXuV0yfbmvzcWnuUmKbav/yTWzK7oL9R0NczF18dm9mjGkwBybxZrMqS2 cnvf5g1wAhUACy9xHVu/e5snAAyapoCJ5fW3h2ydAWbJh08uaJGHTWO0h1gq2RdNDoDV rMuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=efow3zEY; spf=pass (google.com: domain of corentin.jabot@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=corentin.jabot@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id i188sor4148692oia.297.2018.01.08.09.03.27 for (Google Transport Security); Mon, 08 Jan 2018 09:03:27 -0800 (PST) Received-SPF: pass (google.com: domain of corentin.jabot@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.202.90.11 with SMTP id o11mr6537455oib.67.1515431006758; Mon, 08 Jan 2018 09:03:26 -0800 (PST) In-Reply-To: <16c7eb00-967f-49d4-8bd8-38900f4c5cae@isocpp.org> X-Original-Sender: corentin.jabot@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=efow3zEY; spf=pass (google.com: domain of corentin.jabot@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=corentin.jabot@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:36571 Archived-At: --001a113d53bcd70cd0056246c6bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please find my answers bellow, they merely complement the great answers given by jakob. I hope they help, otherwise let me know ! Corentin Le lun. 8 janv. 2018 =C3=A0 16:42, Jakob Riedle a =C3=A9crit : > > > Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com: >> >> Hello, I wanted to share my thoughts on the broad topic of "Concepts as >> Adjectives". >> >> I believe they are not as innocent as presented. >> > > Yes, in my opinion, Concepts as adjectives/qualifiers are very very > powerful and in no way a diffident solution. > > *First,* a new category of user provided entities is silently introduced >> - type decorators. This is bigger a change then implied. >> > > When I first wrote "Concepts are Adjectives, Not Nouns", I very well > perceived them to be ground breaking. > Yet I'm convinced they make *using* the language easier and are it's not a complex feature either. I think it's a natural extension of the current Concepts TS. > > Up until this point all decorations were either keywords or attributes, >> and now we have something which looks like a type (or even a template!), >> used as a qualifier to some other (real) type or auto. >> > > I agree, that it introduces identifiers (in constrast to keyword) as > qualifiers, which is unprecedented by now. > However, this identifier is hardly visually ambiguated with a type name, > because it ultimately is followed by a concrete type (least common case), > "auto" or "typename" (most common cases). > In all situations, the noun is (in 9 of 10 cases) the last identifier, > which sets it visually apart. > In the latter two cases, the noun is a keyword and therefore additionally > visually set apart. > Note that constraints do have an impact on overload resolution, but they do not "qualify" the name in that a Sortable Foo is still a Foo. The list of concepts and the name should be read a single entity to which you apply any other qualifier; (cv) type (ptr-declarator), except now the type may be preceded by a list of concepts names. So I don't think there is any ambiguity. > > Sooner or later people will start asking, why I just can write only the >> decorator and the type be deduced, which the paper actually allow. In th= at >> case question arises do why do we need this new category in the first pl= ace. >> > > Because sometimes, we want to declare a constrained type (Sortable > typename S) and sometimes we want to declare a variable of constrained ty= pe > (Sortable auto s). > If you ask me, I am against making the noun optional in any case. Actuall= y > for the same reason that C++ discourages "const" to implicitly stand for > "const int" (as in C). > While Jakob and I have some disagreements regarding whether auto could be optional, in any case, I don't think there could be any confusion. And why would you use a concept name rather than auto? Because in most cases auto is too vague. especially as a type parameter of a function. Our hope is that a wide use of concepts will lead to cleaner, more comprehensive generic apis. > > > *Second*. Consider const Point arg. const is not about the type, *it's >> about the variable. *The fact that C++ handles const as a different type >> of Point is an implementation detail. >> However "type decorations" will be all about the type, in that one line >> we will have some decorations which *semantically* are about the >> variable and others about the type of it! This is bound to lead to >> confusion. >> > > Wait, do you think going from "template" (without concepts) t= o > "template" is less confusing? > Suddenly, we don't know whether T is a type after all?! > > > > Also. const int a; will always bind to an int b, but a MyClass c, might >> not bind to MyConstraign MyClass d; Yet both are spelled out with the >> same syntax, both are "a case where one is just more constrained then th= e >> other", but in practice mean different things. >> > > Firstly, this argument is not working for me, since const int& will not > bind to a int&. Secondly: > If (which I assume) MyClass is a concrete type, > > - either MyConstrain is a Value-Constraint > (in which case we face same "issue" (IMO, that's a feature), that > Concept TS faces), > - or MyConstrain is a Type-Constraint > (in which case "MyClass" does very well bind to "MyConstraint > MyClass", given MyClass after all meets MyConstraint and doesn't gener= ate a > compiler error) > > Exactly, constraints are assertions on types, not transformations. > > *Third. *Consider A auto a =3D ...; B int b =3D ...; From the C++ rules s= o >> far we might consider both of these are semantically the same, just in t= he >> second case the auto is spelled out. In fact however these two, are >> *radically* different - the first is constrained *type*, the other is >> constrained *value*. This can be confusing no matter how we look at it - >> if we look from variable declaration PoV we expect *both to be types *(b= ut >> they are not) if we look at template argument declaration PoV (, >> ) we expect *both to be a value, *which is also not true! >> > > I understand your concerns. However, this is not how I and Corentin > propose Concepts. > Whether a Concept constraints the type or the value of a variable depends > on the concept, not on whether we "spell out the auto". > "Even" in the phrases "Even int i" and "Even auto i", will always > constrain the values of i. > In the latter phrase however, "auto" is allowed to deduce to any type > (including int), > for which the property "Even" is decidable (depending on the definition, > probably for number-like types). > > > > The confusion with out continues with the fact A auto means one thing in >> code (as return value, variable or argument) and different as template >> param. >> f(A auto a){}; A auto a; A auto f() {} are (*radically*) different then = template> auto I>. >> Yes, one can argue this is already the case, but this does not help >> either, not to mention auto as function params is not yet in. >> > > I AM in favor of "auto" having the same meaning (regarding your concerns) > across its usages. > This is the way I proposed it and I believe Corentin would too. > In all the above cases the constrained are applied to a value. What you may find confusing is just the nature of non type non template template parameters. Which is something I certainly can relate too. Forth*. *Decorations are, by there nature, an ad hoc tool - to have >> something existing and to further specify it in the place of use. >> Constrained types are not like that, ad hoc constrain creation is unlike= ly. Swappable >> Sortable Writable foo; in the real world will likely be just FooConcept >> foo; semantically. It is very unlikely one will need to mix and match >> constrains on the go and pay the syntax, maintenance, visual noise tax. >> > > For the sake of argument, it's irrelevant how likely this feature is used= .. > But if at all unlikely, this is a feature, not a bug. Nobody forces you t= o > chain concepts this way. > Apart from that, I hardly believe, you will write a named concept for eac= h > and every such Concept-based function. > Why would you do so, if you only needed to chain the Concepts once for th= e > whole function? > Additionally, You may want to manipulate multiple properties of an object within the same function. You are not implicitly creating a new concept, you are relying on several. There is a subtle, yet important distinction. Using the same list of concepts name over and over would be a good sign that you indeed, need a new concept name. > > > I believe we should streamline Concepts as much as possible actually >> removing features and "optional syntaxes" before adding new ones. >> > > I agree with you here, although I don't find "Concepts TS revisited" to > make things consistent enough. > > > > When ansering to your concerns, I hope to have understood you correctly > for the most part. > If not, please clarify those mistakes. > > Yours, > Jakob > > -- > 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/16c7eb00-967= f-49d4-8bd8-38900f4c5cae%40isocpp.org > > . > --=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/CA%2BOm%2BSiAYc_BLH2fhH599v9R8oo8HvjhwJnx3d7PVBy= Sa157BA%40mail.gmail.com. --001a113d53bcd70cd0056246c6bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please find my answers bellow, they merely complement the = great answers given by jakob.
I hope they help, otherwise let me know !=

Corentin

Le=C2=A0lun. 8 janv. 2018 =C3=A0=C2=A016:42, Jakob Riedl= e <jakob.riedle@gmail.com&= gt; a =C3=A9crit=C2=A0:


Am Samstag, 6. Januar 2018 14:14:52 UTC+1 schrieb mihailn...@gmail.com:
Hello, I wanted = to share my thoughts on the broad topic of "Concepts as Adjectives&quo= t;.=C2=A0

I believe they are not as innocent as pr= esented.
=C2=A0
Yes, in my opinion, Concepts as adjectives/qualifiers are very very powe= rful and in no way a diffident solution.

First, a new cate= gory of user provided entities is=C2=A0silently introduced - type decorators. T= his is bigger a change then implied.
=C2=A0
When I first wrote "Concepts are Adject= ives, Not Nouns", I very well perceived them to be ground breaking.

Yet I'm convinced they make *= using* the language easier and are it's not a complex feature either. I= think it's a natural extension of the current Concepts TS.=C2=A0=C2=A0=
=C2=A0

Up until this= point all decorations were either keywords or attributes, and now we have = something which looks like a type (or even a template!), used as a qualifie= r to some other (real) type or auto.=C2=A0
=C2=A0
I agree, that it introduces identi= fiers (in constrast to keyword) as qualifiers, which is unprecedented by no= w.
However, this identifier is hardly visually ambiguated with a = type name, because it ultimately is followed by a concrete type (least comm= on case), "auto" or "typename" (most common cases).
In all situations, the noun is (in 9 of 10 cases) the last identifie= r, which sets it visually apart.
In the latter two cases, the nou= n is a keyword and therefore additionally visually set apart.

Note that constraints do have an impact on o= verload resolution, but they do not "qualify" the name in that a = Sortable Foo is still a Foo.
The list of concepts and the name sh= ould be read a single entity to which you apply any other qualifier;
<= div>(cv) type (ptr-declarator), except now the type may be preceded by a li= st of concepts names. So I don't think there is any ambiguity.=C2=A0=C2= =A0
=C2=A0
<= div>

Sooner or later people will start asking, why I ju= st can write only the decorator and the type be deduced, which the paper ac= tually allow. In that case question arises do why do we need this new categ= ory in the first place.
=C2=A0
Because sometimes, we want to declare a constrained type = (Sortable typename S) and sometimes we want to declare a variable of constr= ained type (Sortable auto s).
If you ask me, I am against making = the noun optional in any case. Actually for the same reason that C++ discou= rages "const" to implicitly stand for "const int" (as i= n C).

While Jakob and I have so= me disagreements regarding whether auto could be optional, in any case, I d= on't think there could be any confusion.
And why would you us= e a concept name rather than auto? Because in most cases auto is too vague.= especially as a type parameter of a function.
Our hope is that a= wide use of concepts will lead to cleaner, more comprehensive generic apis= ..=C2=A0


Second. Consider = const Point arg. const is not about the type, it's about the= variable. The fact that C++ handles co= nst as a different type of Point is an implementation detail.=
However "type decorations" will be all about the t= ype, in that one line we will have some decorations which semantically are about the variable and others about the type of it! This is bound to= lead to confusion.
=C2=A0
Wait, do you think going from "template<typename T>= ;" (without concepts) to "template<Sortable T>" is les= s confusing?
Suddenly, we don't know whether T is a type afte= r all?!
=C2=A0


Also. const int a; will alw= ays bind to an int b, but a My= Class c, might not bind to MyConstraign MyClass d; Yet both are spe= lled out with the same syntax, both are "a case where one is just more= constrained then the other", but in practice mean different things.
=C2=A0
Firstly, this ar= gument is not working for me, since const int& will not bind to a int&a= mp;. Secondly:
If (which I assume) MyClass=C2=A0 is a concrete ty= pe,
  • either MyConstrain is a Value-Constraint
    (in which= case we face same "issue" (IMO, that's a feature), that Conc= ept TS faces),
  • or MyConstrain is a Type-Constraint
    (in which= case "MyClass" does very well bind to "MyConstraint MyClass= ", given MyClass after all meets MyConstraint and doesn't generate= a compiler error)
Exactly, constrai= nts are assertions on types, not transformations.
=C2=A0

Third. Con= sider A auto a =3D ...; B int b =3D ..= ..; From the C++ rules so far we might consider both of these are semanti= cally the same, just in the second case the auto is spelled out. In fact ho= wever these two, are radically different - the first is constrained = type, the other is constrained value. This can be confusing n= o matter how we look at it - if we look from variable declaration PoV we ex= pect both to be types (but they are not) if we look at template argu= ment declaration PoV (<auto I>, <int I>) we expect both to b= e a value, which is also not true!
= =C2=A0
I understand your concerns. However= , this is not how I and Corentin propose Concepts.
Whether a Conc= ept constraints the type or the value of a variable depends on the concept,= not on whether we "spell out the auto".
"Even&quo= t; in the phrases "Even int i" and "Even auto i", will = always constrain the values of i.
In the latter phrase however, &= quot;auto" is allowed to deduce to any type (including int),
for which the property "Even" is decidable (depending on the def= inition, probably for number-like types).
= =C2=A0


The confusion with out continues with the fact= A auto means one thing in code= (as return value, variable or argument) and different as template param.
f(A auto a){}; A auto a; = A auto f() {} are (radically) different then template<B auto I>.
Yes, one can argue this is already the case, but this= does not help either, not to mention auto as function params is not yet in= ..

I AM in favor of "auto" having the same meaning (regarding your = concerns) across its usages.
This is the way I proposed it and I = believe Corentin would too.

In = all the above cases the constrained are applied to a value.
What = you may find confusing is just the nature of non type non template template= parameters. Which is something I certainly can relate too.=C2=A0=C2=A0
=C2=A0

Fort= h. Decorations are, by there nature, an= ad hoc tool - to have something existing and to further specify it in the = place of use. Constrained types are not like that, ad hoc constrain creatio= n is unlikely.=C2=A0Swappable Sortable Writable foo; in= the real world will likely be just FooConcept foo; semantically. It is very unlik= ely one will need to mix and match constrains on the go and pay the syntax,= maintenance, visual noise tax.

For the sake of argument, it's irrelevan= t how likely this feature is used.
But if at all unlikely, this i= s a feature, not a bug. Nobody forces you to chain concepts this way.
=
Apart from that, I hardly believe, you will write a named concept for = each and every such Concept-based function.
Why would you do so, = if you only needed to chain the Concepts once for the whole function?
=

Ad= ditionally, You may want to manipulate multiple properties of an object wit= hin the same function. You are not implicitly creating a new concept, you a= re relying on several.
There is a subtle, yet important distincti= on.
Using the same list of concepts name over and over would be a= good sign that you indeed, need a new concept name.

=C2=A0


=
I believe we should streamline Concepts as much as possible actually r= emoving features and "optional syntaxes" before adding new ones.= =C2=A0

I= agree with you here, although I don't find "Concepts TS revisited= " to make things consistent enough.



When ansering to your concerns, I hope to have underst= ood you correctly for the most part.
If not, please clarify those= mistakes.

Yours,
Jakob

--
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-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/16c7eb00-967f-= 49d4-8bd8-38900f4c5cae%40isocpp.org.

--
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/CA%2BOm%2BSiA= Yc_BLH2fhH599v9R8oo8HvjhwJnx3d7PVBySa157BA%40mail.gmail.com.
--001a113d53bcd70cd0056246c6bd-- .