220 36576 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:39:08 +0000 Lines: 475 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="001a11471ee22692590562474726" X-Trace: blaine.gmane.org 1515433052 4001 195.159.176.226 (8 Jan 2018 17:37:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 17:37:32 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC72FQ6X7MLRBSGZZ3JAKGQEIFV7FQI@isocpp.org Mon Jan 08 18:37:28 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYbML-00004t-Pq for gclcip-std-proposals@m.gmane.org; Mon, 08 Jan 2018 18:37:18 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id k74sf1104766oih.4 for ; Mon, 08 Jan 2018 09:39:21 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515433161; cv=pass; d=google.com; s=arc-20160816; b=ciCdeOF/Ct+ZgX66QLFpu2Vzf43ZWJbZV44oycV45tayzd0YpNsPrqrDJo2N3DhYHc 0wbw9kpudDhb5Glx/5j1tIgrcsw3y5Y6BrHxP8oZPg0Nz7oy6Am6vONd1oAMJgV9LUzm xQLTJT7g0yDX76PF5dum++9DlIFdePGhHpI7Y0DpWhMyUPL76ho67vaqP3ci12STgyPW QwIrf0bK3ojouo6qGz6RAnXr6jQoCT5UJvH6tTANUyeC+U1ga8P5R91LzYjnRBqbajdG PUvVK5tNJGph7lGydCckodXzRL0S8Q9ERRCIJGGPQvCHjPajBxkwBM51drRiDNg4KXeK fljg== 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=QXQtWvQGGmu3cY7Pw7NrMtdsG0ua11/oaF/Em/jYxY8=; b=dJEMN9cDEWeVI+/Ws48iaKLDWaosGCVC1cQngquqYcBJinDWaUSM03hEr5XyVhZ5gR ovEumjqQSh6fRVhmNs3cNkbnfnEwoaMF9yIT0YKNPsBUj07Eho458VlAFcDbacdUX3kM 0YH+WaNB5InUV6TvK1TSSasSkslt2+3THX+Csk0AjhcDwNYSr6j0FwTdRvumHmqDSwic 3OEybT0XF6FPQyqer3bjYVn3OyN8zFbqAa057UqkhUnpeOXSjCbYQDK1piI+CTeWN8Tt NMuanR+K0aYbt+DM2um243XqDlDUwgWZCQH6dtp51aJ4dVozqmA1I4+9Dxfy5CCI5Hch 7OSA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cifdlloo; 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=QXQtWvQGGmu3cY7Pw7NrMtdsG0ua11/oaF/Em/jYxY8=; b=vOCKEiHqoXmASPAiMuCaR2rqs3rIGtfxAdbkBwXayLPvd3fulxxBua9MD1x3c6rQUC v/oC25RP/sfT65uWFLQpCdI1By5D9WnkIelL0K8bqN5Mjh0MLoh8xljUQRf1ludE+pdk 8ZLNVc7+CRT8THqjUl+R1qUp77KPfetLwS5rj/gCZp6EKCzrJq/tNRDz6ppxwl86Yc6+ a97KBljsIaB5sjuskRx9EiOmeo5MDtGXqdVezC3YTwih8LiCrKZLlreRLceRIh0TMteU ejrmAW3R1a4I9E17iawnBbM2jbODuPH1DXyhyTv43BtGPYZcFXyMCvjJzHDAWwPXY2Yz Ch3g== 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=QXQtWvQGGmu3cY7Pw7NrMtdsG0ua11/oaF/Em/jYxY8=; b=tY3qrLbMbV3X7gxuaT2YmYBwQBGI+/POulxUi7McrCGg7w4SifXW0FeMatiGA1faTX 7GIIZbdlrMz5QrO1Omexv1wlAn/MzN1iMeo3dPFtUMJcb9OSQlcdwvuUTgS90Voi/WPk yX2kKtMm4HLZkTlxSQEckI2yJTtUwtHC8vlrNeERZ8T8d6q8H33s1/Woczg8UxuBZ7zU Lo9sKwq9TBoARia8hm7jY4Xb/fxvlA89tIcIpKCc8pTwp83vpmFbKJYYFXFTjFNeyiR6 a9BLOKMsvrY4rkW8S5PP32wklkO69UGovKSo1KBv1j3miwXJz+a7FS4ppBeOy5n/TT5l OYwA== X-Gm-Message-State: AKwxyteIU1pPUkZncEyLF4+mys2bPfu9z+adSABAZf5NbW8V0k15SFSS UE46AoWLpwKfKABVyV1aMDsU1g== X-Google-Smtp-Source: ACJfBou+apzwS4wJqxk0Qzlhzc6WbxhOHqa/KEtkZkrBU3krY/8fonoJplb1MpYh7pX22fu9kVS6nQ== X-Received: by 10.157.56.90 with SMTP id r26mr5538619otd.49.1515433161047; Mon, 08 Jan 2018 09:39:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.17.21 with SMTP id g21ls283653ote.18.gmail; Mon, 08 Jan 2018 09:39:20 -0800 (PST) X-Received: by 10.202.171.14 with SMTP id u14mr3848892oie.187.1515433160044; Mon, 08 Jan 2018 09:39:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515433160; cv=none; d=google.com; s=arc-20160816; b=QnQ/ept13bkOViif0AtYu5+TAHeMxUrfnsagNJXfq97B2W4SYxWg45XirVebwZQCE0 lF/DV0nlF/r1+Dwcjb/sd4qeWulKzXNDqWxNwRDQgFXue21ix07VEdYdnSwAg4QtdbBQ JiORwX5Y3WlrlTzkYMdB8SCxi3z4rHQyDBchGykunKj2lIFsIFEZofG8JqgcuxnQycK2 bnJ0ZIBZELsgzJJ5gJbmha4orRfOl9tsF/Ifo245kj3ZqEt/FK6VGMO12g0gej2+vVNl ahwTyzzww6cGvxo5Of93qSNLxpgNpzOVBSBvBu1nOSQTusdERe42gViFfCKDguXiJLoX sfpA== 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=6DKHUNHuNhFZRNt7fjKVxr1NP6cXIZN+kSKyQiVWteY=; b=x5QZWBf5NbocJYiQsjOQkM2q25+GolYUGgFfvR7GWWhIsZCNSzbrpVVuMATxzb1dF2 8uZbXN+alPrKnmOrkFTDMPSF8S5x5yBrnOCM8X/q1TQhsi8s0ASR9X91BeHOh8ggknEJ L3iuca7Euq/wcmufBILVq06nLvCZHSfNQu1MMGTWAs6A2PYrBLXbhgVCNF0HmkeosC1w T5LDq+cVbcLefiWDux01STdRFNCbQEUmS9K3ZbeZWG/KdgFWCTbmPARP9Gc/Yi5M0gC2 lgldC+IpA8vy50jeFr2EeDpqZ5I1DUkYDSLjNvHJO9fNhOJwJNkTViett3qKaQZ61/Na e9EQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cifdlloo; 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 q53sor4214603otd.316.2018.01.08.09.39.20 for (Google Transport Security); Mon, 08 Jan 2018 09:39:20 -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.157.58.6 with SMTP id j6mr6692149otc.261.1515433159454; Mon, 08 Jan 2018 09:39:19 -0800 (PST) In-Reply-To: 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=cifdlloo; 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:36576 Archived-At: --001a11471ee22692590562474726 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Constraints are associated to a type most of the type. Values as in non type non template template parameter are odd enough, and rare enough to begin with that I don't really see them as an issue. Note that a concept can never apply to both a value and a type. `Even` is a value concept. In all other cases, the constrains are associated to a type. Either a single value of that type (auto) , or a type as a whole (typename). Le lun. 8 janv. 2018 =C3=A0 18:22, a =C3=A9crit = : > > > On Monday, January 8, 2018 at 5:42:50 PM UTC+2, Jakob Riedle wrote: >> >> >> >> 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. >> >> >> >> 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 additionall= y >> visually set apart. >> >> >> >> 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 t= hat >>> case question arises do why do we need this new category in the first p= lace. >>> >> >> Because sometimes, we want to declare a constrained type (Sortable >> typename S) and sometimes we want to declare a variable of constrained t= ype >> (Sortable auto s). >> If you ask me, I am against making the noun optional in any case. >> Actually for the same reason that C++ discourages "const" to implicitly >> stand for "const int" (as in C). >> >> >> >> *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) >> to "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 t= he >>> 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 gene= rate a >> compiler error). >> >> > My example was not very clear, but issue is still there, I believe - > copyConstructable T will not bind to any T, however const T does not impo= se > restrictions to the incoming T. > const is not a required clause, copyConstructable is, yet both are used > exactly the same way. > > This mixing of qualifiers could be confusing - sometimes it is about the > *type*, sometimes it is about the *value*, sometime it is about the > *variable*. > > > >> >> *Third. *Consider A auto a =3D ...; B int b =3D ...; From the C++ rules = so >>> far we might consider both of these are semantically the same, just in = the >>> 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 = *(but >>> 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 depend= s >> 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). >> > > Then we still can't tell if the concept is about the type or the value. > Wasn't it one of the original goals to have that distinction? > In any case, I understand variable declaration is a separate issue! > > > >> >> >> >> 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. >> >> >> >> 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 unlik= ely. 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 use= d. >> But if at all unlikely, this is 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? >> >> >> >> 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/c7a4678b-5a2= f-457e-9be4-3979506ce4dd%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%2BSi_HR%3DzjW%3DJi57ve2K8fV4ZSUbyhZXL%2B= Z5RqoRz6Bp5kw%40mail.gmail.com. --001a11471ee22692590562474726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Constraints are associated to a type most of the type.
Values as in non type non template template parameter are odd eno= ugh, and rare enough to begin with that I don't really see them as an i= ssue.

Note that a concept can never apply to both = a value and a type. `Even` is a value concept.

In = all other cases, the constrains are associated to a type. Either a single v= alue of that type (auto) , or a type as a whole (typename).

<= /div>
Le=C2=A0lun. 8 janv. 2= 018 =C3=A0=C2=A018:22, <miha= ilnajdenov@gmail.com> a =C3=A9crit=C2=A0:


On Monday, January 8, 2018 at 5:42:5= 0 PM UTC+2, Jakob Riedle wrote:


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

I believe the= y are not as innocent as presented.
=C2=A0
Yes, in my opinion, Concepts as adjectives/qualifiers are very very = powerful and in no way a diffident solution.
=C2=A0

First, a new category of user provided entities is=C2=A0silently intro= duced - type decorators. This is bigger a change then implied.
=
=C2=A0
When I first wrote "Concepts = are Adjectives, Not Nouns", I very well perceived them to be ground br= eaking.
=C2=A0


Up until this point all decorations wer= e 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) typ= e or auto.=C2=A0
=C2=A0
I agree,= that it introduces identifiers (in constrast to keyword) as qualifiers, wh= ich is unprecedented by now.
However, this identifier is hardly v= isually 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 visuall= y set apart.
=C2=A0


Sooner or la= ter people will start asking, why I just can write only the decorator and t= he type be deduced, which the paper actually allow. In that case question a= rises do why do we need this new category in the first place.
=C2=A0
Because sometimes, we want to declare a co= nstrained type (Sortable typename S) and sometimes we want to declare a var= iable of constrained 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++ discourages "const" to implicitly stand for "const = int" (as in C).



Second. Co= nsider 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 Poin= t is an implementation detail.
However "ty= pe decorations" will be all about the type, in that one line we will h= ave some decorations which semantically are about the variable and o= thers about the type of it! This is bound to lead to confusion.
=
=C2=A0
Wait, do you think going from "temp= late<typename T>" (without concepts) to "template<Sortab= le T>" is less confusing?
Suddenly, we don't know whe= ther T is a type after all?!=C2=A0
=C2=A0


= 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 the other", but in pra= ctice mean different things.
=C2= =A0
Firstly, this argument is not working for me, since const int= & will not bind to a int&. Secondly:
If (which I assume) = MyClass=C2=A0 is a concrete type,
  • either MyConstrain is a= Value-Constraint
    (in which case we face same "issue" (IMO, th= at'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 MyConst= raint and doesn't generate a compiler error).

My example was not very= clear, but issue is still there, I believe - copyConstructable T will not = bind to any T, however const T does not impose restrictions to the incoming= T.
const is not a required clause, copyConstructable is, yet both are used= exactly the same way. =C2=A0

This mixing of qualifi= ers could be confusing - sometimes it is about the type, sometimes i= t is about the value, sometime it is about the variable.




<= /div>
Third= .. Consider A auto a =3D ...; B int= b =3D ...; From the C++ rules so far we might consider both of these ar= e semantically the same, just in the second case the auto is spelled out. I= n fact however these two, are radically different - the first is con= strained type, the other is constrained value. This can be co= nfusing no matter how we look at it - if we look from variable declaration = PoV we expect both to be types (but they are not) if we look at temp= late argument declaration PoV (<auto I>, <int I>) we expect = both to be 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 Concept constraint= s the type or the value of a variable depends on the concept, not on whethe= r we "spell out the auto".
"Even" in the phra= ses "Even int i" and "Even auto i", will always constra= in 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, proba= bly for number-like types).

Then we still can't tell if the concept is about th= e type or the value. Wasn't it one of the original goals to have that d= istinction?
In any case, I understand variable declaration is a = separate issue!=C2=A0

=C2= =A0
=C2= =A0


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

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


Forth. Decorations are, by there nature, an ad hoc tool - = to have something existing and to further specify it in the place of use. C= onstrained types are not like that, ad hoc constrain creation is unlikely.= =C2=A0Swappable Sortable Writable foo; in the real world will likely be just FooConcept foo; semantical= ly. 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 h= ow likely this feature is used.
But if at all unlikely, this is 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 eac= h and every such Concept-based function.
Why would you do so, if = you only needed to chain the Concepts once for the whole function?
=C2=A0


I believe we should streamline Concepts as m= uch as possible actually removing features and "optional syntaxes"= ; before adding new ones.=C2=A0

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



When ansering to your concerns, I hope to have under= stood you correctly for the most part.
If not, please clarify tho= se 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/c7a4678b-5a2f-= 457e-9be4-3979506ce4dd%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= %2BSi_HR%3DzjW%3DJi57ve2K8fV4ZSUbyhZXL%2BZ5RqoRz6Bp5kw%40mail.gmail.com= ..
--001a11471ee22692590562474726-- .