220 35378 <8fe31af5-e98c-3253-0030-85ffe64685d5@honermann.net> article Path: news.gmane.org!.POSTED!not-for-mail From: Tom Honermann Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A plea for a consistent, terse and intuitive declaration syntax Date: Wed, 15 Nov 2017 22:59:17 -0500 Lines: 444 Approved: news@gmane.org Message-ID: <8fe31af5-e98c-3253-0030-85ffe64685d5@honermann.net> References: <1abe0443-19be-4aff-8627-e87d1807b901@isocpp.org> <2ba4fe39-c1bc-c48c-52d3-10a2e61ac699@honermann.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BAF0C1BA1D53EF3681439BB9" X-Trace: blaine.gmane.org 1510804760 1554 195.159.176.226 (16 Nov 2017 03:59:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Nov 2017 03:59:20 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: std-proposals@isocpp.org, =?UTF-8?Q?Thomas_K=c3=b6ppe?= , Jakob Riedle To: Corentin Original-X-From: std-proposals+bncBDBNXSHG6UDBBFU2WTIAKGQEFW374JY@isocpp.org Thu Nov 16 04:59:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f197.google.com ([209.85.216.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFBKa-0008OA-64 for gclcip-std-proposals@m.gmane.org; Thu, 16 Nov 2017 04:59:12 +0100 Original-Received: by mail-qt0-f197.google.com with SMTP id n61sf23120329qte.3 for ; Wed, 15 Nov 2017 19:59:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1510804759; cv=pass; d=google.com; s=arc-20160816; b=V0/emSaEoIq6zeaTWnwDtgLRucw47T0xPKjp6BcetNE72aSkBmXU+trpSKIcz3qRPf 727X2HUaxDAUTHQRosT4CgPx5PVYrMrg/b4satF/FPMouxbZLbgZ+qbWHG4RDWR/1LFj M0vDwleMj6Dq+WkoHQPutYtTgo0/XH6W9x0lymApeRYeAfXU6xdEPaajcse+I3MxhfXV wbA0Po4kQzaP8ogFKznSgMnykvRIWu8GoWBLLOCAfNUiIil1oSK3LpavP73NMGUhDaHm vhafFM5gDMzFrZHzk3BfU0TCKbC9CMh5y7DElRvnVmn8CWzvaFARj1V9JARBqBS4e9Tw Z7Rg== 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:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=oFHeXqNhQwvEOWCgCRptMafPzMPB6gjC60ksQCVk/KE=; b=0pimzNxLSN4cbk9wrl0e1nLQ3Q/OGzJ9hDKJNtxZXb88EC2XtDAyd+wfvfnD/kMnzI izvyKXkTeuB0Hyxx5ctOukQOdeaN9FaU2cBZACt5KACQbjQmiX/JZc2Acxb1c5UOuFF0 n51+wfK6TLV/FVKYSH4c6VO0jyAp++LfaHWbbZYjP9lgrdPQAFInopTSj596RzqSuEyF gVxOLj7Up32FvCi+sZ1o6NiUYJ2UlAmp220zIioXT42pqpFt9oTslnX+/oMSfcpkm49V wLzagauC/jg21ng5lu/AIjlXanKoEhOKSQunvBAkhKWgJtT9+CHLfNxeN5mCBDMywVOP 3qDA== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 173.203.187.99 is neither permitted nor denied by best guess record for domain of tom@honermann.net) smtp.mailfrom=tom@honermann.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language: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=oFHeXqNhQwvEOWCgCRptMafPzMPB6gjC60ksQCVk/KE=; b=TWzrMmG7xLNkEi166EVtIkZgW/DBhBM80eTIVzcPwVkgz14g4QT99a+0862gDgbbIy tcArKRJGswfZUz/5tNXKvWwKi8pQbX9EYLx4b4USlI2FGc6o9+5nxKxi0W8cL5s7y/kC q4vILWQzqOuoBkza7m7VY/cnhb2niQpe8SlOd99JO0mbfR585fUnl/PxO4uHSPmqYk6A IRtSggMdrq1l5iMPVK6n1qiL+CzVLpf1ndIeqb8fzmwYYc88fhynEPw0ugqyD4rY4Vpz XqizLAVRCwEtj4vkZ2N04LqjhOt8ZDxl9qw/M/gUWQDKFr30rU1fwzP0V3Z6LiXyvVhZ gXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :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=oFHeXqNhQwvEOWCgCRptMafPzMPB6gjC60ksQCVk/KE=; b=guO6DpW/BfA79EbK+fB1Ehx73Rr2n8MfaR+0+BBd0EUUCXDJaYXUhSmUXbZpZaVrvW QufKPWmVr0tVwJrBmF5jurxPxDAgEBw2kBUxAx8rMIMoPPFf8Bf8cSkkM4BOD+Zrngdv 1y9NSa9aqTelRwyr0ihMtEf7bHyeQkZPzi6TdShxrPJ1OzJe+Nhd5MVtYSxmkEY0dFvf no9hWuV+niJ7K13OEugr1t/u2M/N7FZdx3zVN/AIU9Wdcd0EjVdm3c7847qTDHa08LT+ zOPcrEMEmD1VF2UHhNvv3kAMO+wfzQxjkhhBxgDwS1C5s4ywMgd6juDe1lUFsXkDNIgF X-Gm-Message-State: AJaThX5Yo7CUWqDCipV1T7LtV5Ly33UvXB0Xz2AkiNR9Ex8h+P4xOfvl sFzXZSYu+yo1dmxynurQWow= X-Google-Smtp-Source: AGs4zMa3wWuT1u6ssv4zZzlKg7td+bPwtr+9NwUw6oAVn0k4pWiBGPQjNtIDHPcF2zrPAf60cVGHDg== X-Received: by 10.200.56.226 with SMTP id g31mr235796qtc.12.1510804759125; Wed, 15 Nov 2017 19:59:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.237.62.110 with SMTP id m43ls366599qtf.6.gmail; Wed, 15 Nov 2017 19:59:18 -0800 (PST) X-Received: by 10.200.43.78 with SMTP id 14mr492483qtv.72.1510804758400; Wed, 15 Nov 2017 19:59:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510804758; cv=none; d=google.com; s=arc-20160816; b=mZ7oVR7XFFVB2+OkKDTLoAcdj1mZTY+KJ9od+V9AddEiZ/nKpSEZhCLk1qegkM4QJh rJ1LeqfJRHGj8petWICBD8bJzfl5MDwqZvmsjsjgkCn6KrkpQ8E5rcpN4ygdJd/Kh+Qe W6s7VFqIGdtPO1fRbkPqBaZO0aZLJgYOlnHu9fVvMzpitaSAZgy1Fb/Io4fGv3bV0C94 1SOQ8HlqSHf/Pym7x4vKa040p/a64ofA21I0rKIEmTjUfLzRF7NX3yQ6jEF151Z5S9d+ trd3d16u8owgrOP5YHF4m+UPSdviAiRSRIIvpr1gWgSTLj09Y6D+koN7cv4noMYC1aJ0 mNPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=sC+mHQNsUB1tDTBVfh5uJfJYC1Pnz9O5ENN82TxeJtE=; b=iLIi7eUNzvpXFx8Y0eW6mk8HSkL4OnuOkrikhFIclch4UWmC6hMgkJoPoTj4VxlLD0 K41Aezw6bxYKsFxOqU5Am5UWet7DXEucB61bRBqEZ/jPZ05fYY85LFwBISOEI3Fd/owR iZ3ZOGNZyq1BkM+B83IuO7eCVSCIe3EH87rCs03JqvS4Dkk6BQBqippr1zXK9puiDgKH 4+bnsLPTmWjwg2AWJjEmn7lO/GY89RGvBEgZ1sluDOo1FOUb5b9YpsGm8931FYbJOLEZ NXM2R/kWt+Ej3stITdn+m9DciSLgw3aMV1cmSXQnxBiKh9LKnHG2AH3J6aWXDftw9Ppx 8ygg== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 173.203.187.99 is neither permitted nor denied by best guess record for domain of tom@honermann.net) smtp.mailfrom=tom@honermann.net Original-Received: from smtp99.iad3a.emailsrvr.com (smtp99.iad3a.emailsrvr.com. [173.203.187.99]) by mx.google.com with ESMTPS id x94si168757qtd.470.2017.11.15.19.59.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 19:59:18 -0800 (PST) Received-SPF: neutral (google.com: 173.203.187.99 is neither permitted nor denied by best guess record for domain of tom@honermann.net) client-ip=173.203.187.99; Original-Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 021575A89; Wed, 15 Nov 2017 22:59:18 -0500 (EST) X-Auth-ID: tom@honermann.net Original-Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: tom-AT-honermann.net) with ESMTPSA id B16A85BA9; Wed, 15 Nov 2017 22:59:17 -0500 (EST) X-Sender-Id: tom@honermann.net Original-Received: from [192.168.1.23] (pool-173-53-30-126.rcmdva.fios.verizon.net [173.53.30.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 15 Nov 2017 22:59:17 -0500 In-Reply-To: Content-Language: en-US X-Original-Sender: tom@honermann.net X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 173.203.187.99 is neither permitted nor denied by best guess record for domain of tom@honermann.net) smtp.mailfrom=tom@honermann.net 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:35378 Archived-At: This is a multi-part message in MIME format. --------------BAF0C1BA1D53EF3681439BB9 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable On 11/15/2017 12:22 PM, Corentin wrote: > Le=C2=A0mer. 15 nov. 2017 =C3=A0=C2=A016:57, Tom Honermann > a =C3=A9crit=C2=A0: > > > I like the discussion in 2.4.4; I don't think I've seen anyone > suggest use of concept names in place of 'typename' for dependent > name disambiguation.=C2=A0 I'm not yet sure if this is a good idea, b= ut > it is interesting to think about.=C2=A0 I presume that the named > concept's prototype parameter must be a type template parameter > for use in place of 'typename'.=C2=A0 Perhaps you could also allow a > concept with a prototype template template parameter to be used in > place of 'template' disambiguation.=C2=A0 Would you also allow a > concept with a non-type prototype template parameter to be used > where 'typename' and 'template' disambiguation is not required?=C2=A0 > I'm not sure that this is useful, nor whether it is reasonably > possible within the existing grammar. > > > The idea comes=C2=A0P0634, and the general observation that=C2=A0typename= is one=20 > of this thing that gets mindlessly and grudgingly added by junior=20 > developers when the compiler is unhappy. Hopefully, replacing that=20 > keyword with actual information will make people think more about what=20 > they are doing, and add information for subsequent readers. And=20 > typename was already a constraint in that it force the type of the=20 > identifier to be a type. If that make sense. > > If I understand you correctly, what your propose would be like having=20 > a constrained "valuename" ? The compilers could probably deal with it,=20 > however would it add readability ? > You probably don't want to loose the "this is a type" information for=20 > the human reader. I didn't intent to propose it, nor suggest that it might be useful, but=20 maybe worth thinking about.=C2=A0 Maybe.=C2=A0 I can't think of a reasonabl= y=20 motivating example.=C2=A0 In each example I've thought of, I find myself=20 thinking the constraint belongs in the requires clause of the template.=C2= =A0=20 But that seems likely to be true for cases where you would specify a=20 concept name in place of 'typename' or 'template' as well, so maybe=20 there just isn't much motivation for this at all. > > In section 2.4.5, I believe it is already allowed to specify > constrained parameters in template alias declarations.=C2=A0 I don't > understand the final example; is 'Stream' effectively a concept > alias (I assume 'Iterable' names a concept)?=C2=A0 That declaration > also looks like a partial specialization of a template alias, but > those don't exist.=C2=A0 Perhaps you intended 'template > using Stream =3D Iterable'? > > > > The idea that actually was suggested by several people independently,=C2= =A0=20 > was to allow a an alias of a template type to be more constrained than=20 > the original type. in this poorly made and explained example, Stream=20 > is an alias on the Iterate=C2=A0template type, however it puts additional= =20 > requirements=C2=A0on the type ( or non type ) of its template parameter. = In=20 > insight, it may be worth of its own paper. I wouldn't say it's a=20 > specialization, since it does not affect the declaration. The semantics are still unclear to me; I think this section could use=20 some more explanation as well as an example.=C2=A0 How do I use this 'Strea= m'=20 alias?=C2=A0 Is 'Stream X;' a valid declaration that is only=20 well-formed if 'MyType' satisfies both 'Iterable' and 'Serializable'?=C2=A0= =20 Can I use 'Stream' as a constrained-parameter as in 'template=20 class X;'?=C2=A0 If so, this seems to be introducing a concept alias as=20 opposed to a type alias; which seems unnecessary since=20 'template concept Stream =3D requires Serializable &&=20 Iterable' achieves the same result. Assuming I'm following correctly, I think a different syntax is=20 necessary since 'template using Stream =3D ...' is the= =20 syntax that would be expected for a partial specialization of an alias=20 template (if such things existed).=C2=A0 This is why I asked if the '' a= t=20 the end of 'Stream' is really intended. > In section 2.5: I think it is potentially useful to allow > constraints to be specified on pointers and references just as we > can with existing type qualifiers.=C2=A0 For example: > =C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The type of 'p' m= ust > satisfy PointerToIntegral. > > > Maybe ? I feel like this would have very limited use. =C2=A0We have synta= x=20 > to describe qualifiers, I don't think concepts add a lot information=20 > there. > But why not, as long as compilers writers have no reasons to be=20 > opposed to it. I agree the uses would be relatively rare, but I like that this follows=20 the existing rules for type qualifiers.=C2=A0 It does complicate interactio= n=20 with 'const' and 'volatile', but perhaps no more so than is necessary=20 anyway.=C2=A0 I think your section 2.5 could provide an example like the=20 following: =C2=A0 const Fooable auto foo =3D {}; =C2=A0 Fooable const auto foo =3D {}; =C2=A0 const auto foo Fooable =3D {};=C2=A0 // ill-formed because the cons= traint=20 follows the name? =C2=A0 Fooable auto foo const =3D {}; =C2=A0 auto foo const Fooable =3D {};=C2=A0 // ill-formed because the cons= traint=20 follows the name? =C2=A0 auto foo Fooable const =3D {};=C2=A0 // ill-formed because the cons= traint=20 follows the name? Are all of these semantically equivalent?=C2=A0 Are some ill-formed as indi= cated? > > > In section 3, note that 'void foo(ConceptName auto a, decltype(a) > b)' is *not* equivalent to the consistent resolution behavior > specified in the concepts TS because the type of the argument for > 'b' does not contribute to type deduction.=C2=A0 See P0725 [2] for so= me > discussion of this.=C2=A0 Specifying consistent resolution when conce= pt > names are not required to deduce the same type requires a template > header.=C2=A0 For example: > =C2=A0 template void foo(T a, T b); > > > That's true. And I'm not arguing against that syntax. I'm arguing that=20 > in functions template with auto parameter, each constraint should only=20 > apply to the type immediately following. > Note that this does not break your example, ConceptName only appears=20 > once in front of T. Right, you are arguing for independent resolution; which I'm in favor of=20 as well.=C2=A0 The point I was trying to make is that 'void foo(ConceptName= =20 auto a, decltype(a) b)' is probably *not* the desired semantics in most=20 cases (though it is in some cases). Tom. --=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/8fe31af5-e98c-3253-0030-85ffe64685d5%40honermann= ..net. --------------BAF0C1BA1D53EF3681439BB9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 11/15/2017 12:22 PM, Corentin wrote:<= br>
Le=C2=A0mer. 15 nov. 2017 =C3=A0=C2=A016:57, Tom Honermann <= ;tom@honermann.net> a =C3=A9crit= =C2=A0:
=C2=A0

I like the discussion in 2.4.4; I don't think I've seen anyone suggest use of concept names in place of 'typename' for dependent name disambiguation.=C2=A0 I'm not yet sure if this is a good idea, but it is interesting to think about.=C2=A0 I presume that the named concept's prototype parameter must be a type template parameter for use in place of 'typename'.=C2=A0 Perhaps you could als= o allow a concept with a prototype template template parameter to be used in place of 'template' disambiguation.=C2=A0 Would you also allow a concept with a non-type prototype template parameter to be used where 'typename' and 'template' disambiguation is not required?=C2=A0 I'm not sure that this is useful, nor wheth= er it is reasonably possible within the existing grammar.

The idea comes=C2=A0P0634, and the general observation that=C2=A0typename is one of this thing that gets mindlessly an= d grudgingly added by junior developers when the compiler is unhappy. Hopefully, replacing that keyword with actual information will make people think more about what they are doing, and add information for subsequent readers. And typename was already a constraint in that it force the type of the identifier to be a type. If that make sense.

If I understand you correctly, what your propose would be like having a constrained "valuename" ? The compilers could probably deal with it, however would it add readability ?
You probably don't want to loose the "this is a type" information for the human reader.

I didn't intent to propose it, nor suggest that it might be useful, but maybe worth thinking about.=C2=A0 Maybe.=C2=A0 I can't think of a reasonably motivating example.=C2=A0 In each example I've thought of, I find myself thinking the constraint belongs in the requires clause of the template.=C2=A0 But that seems likely to be true for cases where you would specify a concept name in place of 'typename' or 'template' as well, so maybe there just isn't much motivation for this at all.

=C2=A0

In section 2.4.5, I believe it is already allowed to specify constrained parameters in template alias declarations.=C2=A0 I don't understand the final example; i= s 'Stream' effectively a concept alias (I assume 'Iterable' names a concept)?=C2=A0 That declaration also looks like a partial specialization of a template alias, but those don't exist.=C2=A0 Perhaps you intended 'template<Serializable T> using Stream =3D Iterable<T>'?


The idea that actually was suggested by several people independently,=C2=A0 was to allow a an alias of a template ty= pe to be more constrained than the original type. in this poorly made and explained example, Stream is an alias on the Iterate=C2=A0template type, however it puts additional requirements=C2=A0on the type ( or non type ) of its template parameter. In insight, it may be worth of its own paper.=C2= =A0I wouldn't say it's a specialization, since it does not affect the declaration.

The semantics are still unclear to me; I think this section could use some more explanation as well as an example.=C2=A0 How do I use thi= s 'Stream' alias?=C2=A0 Is 'Stream<MyType> X;' a valid declaration that is only well-formed if 'MyType' satisfies both 'Iterable' and 'Serializable'?=C2=A0 Can I use 'Stream' as a constrained-parameter as = in 'template<Stream T> class X;'?=C2=A0 If so, this seems to be introducing a concept alias as opposed to a type alias; which seems unnecessary since 'template<typename T> concept Stream =3D requires Serializable<T> && Iterable<T>' achieves the same result.

Assuming I'm following correctly, I think a different syntax is necessary since 'template<Serializable T> using Stream<T> =3D ...' is the syntax that would be expected for a partial specialization of an alias template (if such things existed).=C2=A0 This is why I asked if the '<T>' at the end of 'Stream' is really intended.

=C2=A0
In section 2.5: I think it is potentially useful to allow constraints to be specified on pointers and references just as we can with existing type qualifiers.=C2=A0 For example:
=C2=A0 auto * PointerToIntegral p =3D ...;=C2=A0 // The typ= e of 'p' must satisfy PointerToIntegral.

Maybe ? I feel like this would have very limited use.=C2=A0 =C2=A0We have syntax to describe qualifiers, I don't think concepts add a lot information there.=C2=A0=C2=A0
But why not, as long as compilers writers have no reasons to be opposed to it.

I agree the uses would be relatively rare, but I like that this follows the existing rules for type qualifiers.=C2=A0 It does complicat= e interaction with 'const' and 'volatile', but perhaps no more so than is necessary anyway.=C2=A0 I think your section 2.5 could provide an example like the following:

=C2=A0 const Fooable auto foo =3D {};
=C2=A0 Fooable const auto foo =3D {};
=C2=A0 const auto foo Fooable =3D {};=C2=A0 // ill-formed because the c= onstraint follows the name?
=C2=A0 Fooable auto foo const =3D {};
=C2=A0 auto foo const Fooable =3D {};=C2=A0 // ill-formed because the c= onstraint follows the name?
=C2=A0 auto foo Fooable const =3D {};=C2=A0 // ill-formed because the c= onstraint follows the name?

Are all of these semantically equivalent?=C2=A0 Are some ill-formed as indicated?


=C2=A0

In section 3, note that 'void foo(ConceptName auto a, decltype(a) b)' is *not* equivalent to the consistent resolution behavior specified in the concepts TS because the type of the argument for 'b' does not contribute to type deduction.=C2=A0 See P0725 [2] for some discussion of this.=C2=A0 Specifying consistent resolution when concept names are not required to deduce the same type requires a template header.=C2=A0 For example:
=C2=A0 template<ConceptName typename T> void foo(T a,= T b);

That's true. And I'm not arguing against that syntax. I'm arguing that in functions template with auto parameter, each constraint should only apply to the type immediately following.
Note that this does not break your example, ConceptName only appears once in front of T.

Right, you are arguing for independent resolution; which I'm in favor of as well.=C2=A0 The point I was trying to make is that 'void foo(ConceptName auto a, decltype(a) b)' is probably *not* the desired semantics in most cases (though it is in some cases).

Tom.

--
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.goog= le.com/a/isocpp.org/d/msgid/std-proposals/8fe31af5-e98c-3253-0030-85ffe6468= 5d5%40honermann.net.
--------------BAF0C1BA1D53EF3681439BB9-- .