220 39940 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named Parameters for C++ Date: Mon, 20 Aug 2018 13:18:34 -0700 (PDT) Lines: 388 Approved: news@gmane.org Message-ID: References: <1708615.QdClGnisbJ@tjmaciei-mobl1> <60fba045-252b-486e-92e0-03c08b6d5a35@wanadoo.fr> <1925737.EHUJpxQoH7@tjmaciei-mobl1> <4df1f86f-cdee-5275-bdd1-b53f2f10bef8@wanadoo.fr> <7e07b857-8be0-f0b4-79e2-32d0f2d8e823@wanadoo.fr> <7d28cd24-b43d-4e24-876b-a04adcbbe867@isocpp.org> <19c6eb56-2188-b849-6ea1-87b37cb546de@wanadoo.fr> <3fc9fb1a-8803-4bcf-b928-c855e76f880e@isocpp.org> <01a106d3-cdaa-e348-2275-4222eed34dda@wanadoo.fr> <67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org> <0d02cfac-0504-62d2-9835-b400daff972b@wanadoo.fr> <9f3550db-0cce-4259-85ef-428d8cfba63c@isocpp.org> <89483da2-1435-49ef-94ea-d9d90fbac549@isocpp.org> <333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1242_1255399920.1534796314698" X-Trace: blaine.gmane.org 1534796191 9880 195.159.176.226 (20 Aug 2018 20:16:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 20:16:31 +0000 (UTC) Cc: jmckesson@gmail.com, mihailnajdenov@gmail.com, bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBG6E5TNQKGQELZPACAA@isocpp.org Mon Aug 20 22:16:27 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frqbC-0002R8-E3 for gclcip-std-proposals@m.gmane.org; Mon, 20 Aug 2018 22:16:26 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id 188-v6sf8656835ybv.9 for ; Mon, 20 Aug 2018 13:18: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:cc: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=a0aySSyAKTAJeuZqNLftec2d25f4g6mcIJO82io7q/c=; b=NzeX7tISXKjPPZ4mxdlinfqha1PShT70Fur8NIGFMAWUX5gIWLgP/aET0xwaoW2Mmb 9xSPojz2xgfXxABYDo+wcFbyMVXxikZ3D7JaoQpddr+ZDCHqcK1+59J9LfCKrKhEUDax LsmJOUg7bj7e8xOdHoAQJVMzpei+y54sSPMeNNjsutP7YwOYV2wwL+Tmm9ZTyn2iM7Xy pNFhna5Cl82thEAjMN4hU2jAey7C1OEdBzklsXdPdDTYK9vptma64ghohi3JpoYww+D2 pfTM8D7FrMihFQOFRVrAAyApJBGnlfcM2LSKPRFHE1tIEempKLL2prFsKGvMtxiIRZTR W0fQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=a0aySSyAKTAJeuZqNLftec2d25f4g6mcIJO82io7q/c=; b=piIoyPY1e5mw7YkpMYJwXIhGdJdNuGU8B0jPql5X3uTuMQ7tEOVU6UWb8fY0TOr3gu frizkZ8C63vlQgOwGWnRLF+XOVI/BIZN/CxC3ukNXMYlT2/pthaDloRG9AEzLInEUZ6Y 0hBB3am23+fp0jq+ZtkIhYNDHrDTuV70cDYC6ZnKOj2CfrS1enpjczLZYiUV+mH9vMwa Ul1jcygdKGLEwiNL/6VuQeaEbQncVM0AkYtBkJ8ad1E3Tqa+3TY+gljP27IlC88QYsyq ydz1RWZAmxb7R7IGWnglTAKAidoHhx6El2EdoPC9T396itGbe8dYA6AYb5rhdmv+doJY eweg== 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:cc: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=a0aySSyAKTAJeuZqNLftec2d25f4g6mcIJO82io7q/c=; b=Gk3pCLw9aGLBIQ5Z5W5Mo9IkB6AKAqo34hOj8AJWgCnybOS7nA8Eyh9/je6XJtrzRc 6WuHls3alpUJhl4gb7c7C4jy6crnNivhrHwSlewV9iPbH3wrOuPsV6sSUaYH4djJh2yv bqCqW6Rhm6EJGj9/wJsm+S8gVEGBVQHApa8bxWeoIl4HchuAhfiMH5JPrwYEu/TFKY9V OiR06TCCm/ezKgblVInrWkr9aDkSNvOE0Pf/vTCxu0UeOBFkIG0xpkIuBfnRZXdT2Mt9 UfVASx82pgAVdkoRnbYh/DzxttuPJFbIPvQzS61qpwj+0PBf1aCQU6QTNAyceKd+oI9S px+g== X-Gm-Message-State: APzg51DXPMPu801qUblBNjUBBYgkZsrnK9RubYdlPX9fi3XnFdQKQyRQ G9XTBihadgy+Rotd6ZzLPXsXzw== X-Google-Smtp-Source: ANB0VdYAbZ2je2w0MRH968ahqyxk+YYbcqii3cVWI+tvFcWAtU7RNoaFkg84bASyuU5cGhe6YInVWg== X-Received: by 2002:a81:b71b:: with SMTP id v27-v6mr1412575ywh.3.1534796316587; Mon, 20 Aug 2018 13:18:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:52cb:: with SMTP id g194-v6ls1359197ywb.38.gmail; Mon, 20 Aug 2018 13:18:35 -0700 (PDT) X-Received: by 2002:a0d:de01:: with SMTP id h1-v6mr740337ywe.3.1534796315310; Mon, 20 Aug 2018 13:18:35 -0700 (PDT) In-Reply-To: <333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org> X-Original-Sender: MihailNajdenov@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:39940 Archived-At: ------=_Part_1242_1255399920.1534796314698 Content-Type: multipart/alternative; boundary="----=_Part_1243_199046079.1534796314699" ------=_Part_1243_199046079.1534796314699 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote: > > > > On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.com=20 > wrote: >> >> >> >> On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote: >>> >>> >>> >>> On Monday, August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escrib= a=20 >>> wrote: >>>> >>>> Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit : >>>> >>>> >>>> >>>> On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet=20 >>>> Escriba wrote:=20 >>>>> >>>>> Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit : >>>>> >>>>> >>>>> >>>>> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet=20 >>>>> Escriba wrote:=20 >>>>>> >>>>>> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit : >>>>>> >>>>>> >>>>>> >>>>>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet=20 >>>>>> Escriba wrote:=20 >>>>>>> >>>>>>> Independently of the language feature, using a tag type allows to= =20 >>>>>>> transport the tag between different functions. In addition, you=20 >>>>>>> cannot=20 >>>>>>> change the class constructor name, so you will need a tag to be abl= e=20 >>>>>>> to=20 >>>>>>> overload it. Take for example the in_place_t tag.=20 >>>>>>> >>>>>> >>>>>> I have thoroughly explored that idea a month back:=20 >>>>>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GX= b0/4OjT5Z4pBQAJ >>>>>> >>>>>> Feel free to comment there, I am undecided on the topic.=20 >>>>>> >>>>>> =20 >>>>>> >>>>>> I'm not sure yet we need some syntactic sugar for this tag=20 >>>>>> dispatching feature neither. >>>>>> I'm just trying to separate the named parameter part from the=20 >>>>>> overload part as orthogonal features. >>>>>> You go too far for my taste in your proposal and you propose to have= =20 >>>>>> all at once. I'll be against such a feature. >>>>>> >>>>> ... >>>>> >>>>> Lastly, it should be noted that tagged dispatch doesn't help with wha= t=20 >>>> I will refer to as "mega-functions": functions that take stupidly larg= e=20 >>>> numbers of relatively independent parameters, but for some reason don'= t=20 >>>> want to take them as a convenient aggregate. This is a use case that s= ome=20 >>>> people want to support, to avoid conceptual two-stage construction. >>>> >>>> IMHO, this case is covered by weak named parameters already. >>>> >>> >>> =20 >> >>> Then perhaps you're not understanding what a "mega-function" is. We're= =20 >>> talking about functions with *dozens* of parameters, most of which are= =20 >>> optional. Consider all of the various parameters you deal with when set= ting=20 >>> up a window. Window styles, size, position, hierarchy, font choice, and= =20 >>> other things. Each of those are conceptually one or more parameters to = the=20 >>> window creation function. >>> >>> "Ideally", these would be literal parameters to a hypothetical Window= =20 >>> class's constructor. But they're not; most such classes give relatively= =20 >>> limited numbers of parameters to the Window's constructor. The rest are= =20 >>> values set after the Window's construction, which means that defaults a= re=20 >>> used until those get set. Basically, it's two-stage construction. >>> >>> The only way you can get the "ideal" case is if order for parameters is= *completely=20 >>> removed* for such functions. You can specify the arguments in any order= =20 >>> when you call them, and the caller can default any parameter with a def= ault=20 >>> value simply by not specifying it. >>> >>> Weak named parameters can't do that. Tag dispatch can't do that (not=20 >>> without extraordinary pain on the callee side). Even designated=20 >>> initializers have to be specified in the right order. >>> >> >> =20 > Are sure about that? Argument rearrangement is doable without changing th= e=20 >> signature (a.k.a. strong) >> > > Maybe we have very different ideas about what "strong named parameters"= =20 > means. The question of "changing the signature" is not the distinction=20 > between "strong" and "weak". At least, it's not the distinction that I'm= =20 > talking about it. > > "Weak named parameters" to me refers to named parameters which are all of= =20 > the following: > > 1. Optional. You can call a function that has named parameters without=20 > naming the parameter(s) at the call site. > 2. Ordered. The order of the arguments must match the parameter order of= =20 > the function, regardless of the names you specify at the call site. > 3. Overload-neutral. The presence or absence of names at the call site ha= s=20 > no effect on function overloading. > > Essentially, if your rules require that all named parameter function call= s=20 > will invoke the same function with the same behavior if you stripped out= =20 > all of the names, then the named parameter proposal is "weak". > > Any named parameter feature which imposes rules antithetical to at least= =20 > one of the above is "strong". With the strongest being the antithesis to= =20 > all of them. > I see, for you weak refers to the notion the call is the same, but=20 unchecked, without them. For me strong is referring to "does it introduce a new signature", the same= =20 way strong typedef introduces a new type. Everything else is weak as it is= =20 about the compiler not the code. Changing the signature is a clear boundary in both semantics and=20 implementation. =20 But in the realm of non-changing-the-signature names, a lot can be done,=20 granted the calls *will* differ w/ and w/o names.=20 Should it be done is a different matter, this is a debate as heated as the= =20 one about signature - some people consider names useless if they don't=20 rearrange/skip defaults, some are happy with just checking alone. =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/a9c81a6a-3fdb-41c3-afee-9e5041f6815f%40isocpp.or= g. ------=_Part_1243_199046079.1534796314699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, August 20, 2018 at 9:45:02 PM UTC+3, Ni= col Bolas wrote:


On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@g= mail.com wrote:


On Monday, August 20, 2018 at 6:37:39 PM UTC+3, Nicol Bolas wrote:=


On Monday,= August 20, 2018 at 2:15:17 AM UTC-4, Vicente J. Botet Escriba wrote: =20 =20 =20
Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0:
=20


On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escriba wrote:
Le 19/08/2018 =C3=A0 19:22, mihailn...= @gmail.com a =C3=A9crit=C2=A0:


On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba wrote:
Le 19/08/2018 =C3=A0 15:04, mi= hailn...@gmail.com a =C3=A9crit=C2=A0:


On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba wrote:
Independent= ly of the language feature, using a tag type allows to
transport the tag between different functions. In addition, you cannot
change the class constructor name, so you will need a tag to be able to
overload it. Take for example the in_place_t tag.


Feel free to comment there, I am undecided on the topic.=C2=A0

=C2=A0
I'm not sure yet we need some syntactic sugar for this tag dispatching feature neither.
I'm just trying to separate the named parameter par= t from the overload part as orthogonal features.
You go too far for my taste in your proposal and you propose to have all at once. I'll be against such a feature.
...
<= /blockquote>
Lastly, it should be noted that tagged dispatch doesn't help with what I will refer to as "mega-functions": fun= ctions that take stupidly large numbers of relatively independent parameters, but for some reason don't want to take them as a convenient aggregate. This is a use case that some people want to support, to avoid conceptual two-stage construction.
IMHO, this case is covered by weak named parameters already.
<= /blockquote>

=C2=A0
Then perhaps y= ou're not understanding what a "mega-function" is. We're = talking about functions with dozens of parameters, most of which are= optional. Consider all of the various parameters you deal with when settin= g up a window. Window styles, size, position, hierarchy, font choice, and o= ther things. Each of those are conceptually one or more parameters to the w= indow creation function.

"Ideally", thes= e would be literal parameters to a hypothetical Window class's construc= tor. But they're not; most such classes give relatively limited numbers= of parameters to the Window's constructor. The rest are values set aft= er the Window's construction, which means that defaults are used until = those get set. Basically, it's two-stage construction.
The only way you can get the "ideal" case is if orde= r for parameters is completely removed for such functions. You can s= pecify the arguments in any order when you call them, and the caller can de= fault any parameter with a default value simply by not specifying it.
=

Weak named parameters can't do that. Tag dispatch c= an't do that (not without extraordinary pain on the callee side). Even = designated initializers have to be specified in the right order.
<= /div>

=C2=A0
=
Are sure about that? Argument rearrangement is doable without changing t= he signature (a.k.a. strong)

<= div>Maybe we have very different ideas about what "strong named parame= ters" means. The question of "changing the signature" is not= the distinction between=20 "strong" and "weak". At least, it's not the distinc= tion that I'm talking about it.

"Weak nam= ed parameters" to me refers to named parameters which are all of the f= ollowing:

1. Optional. You can call a function tha= t has named parameters without naming the parameter(s) at the call site.
2. Ordered. The order of the arguments must match the parameter ord= er of the function, regardless of the names you specify at the call site.
3. Overload-neutral. The presence or absence of names at the c= all site has no effect on function overloading.

Es= sentially, if your rules require that all named parameter function calls wi= ll invoke the same function with the same behavior if you stripped out all = of the names, then the named parameter proposal is "weak".

Any named parameter feature which imposes= rules antithetical to at least one of the above is "strong". Wit= h the strongest being the antithesis to all of them.

I see, for you weak refers to the notion the call= is the same, but unchecked, without them.

For me = strong is referring to "does it introduce a new signature", the s= ame way strong typedef introduces a new type. Everything else is weak as it= is about the compiler not the code.

Changing the = signature is a clear boundary in both semantics and implementation. =C2=A0<= /div>

But in the realm of non-changing-the-signature nam= es, a lot can be done, granted the calls will differ w/ and w/o name= s.=C2=A0
Should it be done is a different matter, this is a debat= e as heated as the one about signature - some people consider names useless= if they don't rearrange/skip defaults, some are happy with just checki= ng alone. =C2=A0

--
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/a9c81a6a-3fdb-41c3-afee-9e5041f6815f= %40isocpp.org.
------=_Part_1243_199046079.1534796314699-- ------=_Part_1242_1255399920.1534796314698-- .