220 39938 <333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named Parameters for C++ Date: Mon, 20 Aug 2018 11:45:01 -0700 (PDT) Lines: 555 Approved: news@gmane.org Message-ID: <333693b1-38a8-424f-bc15-0b36131b97f4@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_490_2044119226.1534790702057" X-Trace: blaine.gmane.org 1534790580 19293 195.159.176.226 (20 Aug 2018 18:43:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 18:43:00 +0000 (UTC) Cc: jmckesson@gmail.com, mihailnajdenov@gmail.com, bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBL4Y5TNQKGQEAKG6EHY@isocpp.org Mon Aug 20 20:42:56 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 1frp8g-0004q5-2n for gclcip-std-proposals@m.gmane.org; Mon, 20 Aug 2018 20:42:54 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id x13-v6sf8380405ybl.17 for ; Mon, 20 Aug 2018 11:45:04 -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=ftrYuJ10grD5ExsJhHz2A/aXRZAlBjgBaH79bs2PF48=; b=pY+ka8kotM7z6klvqAqAvNJlFVGZAKMv+I+q+hQ3t7jUVXT6Ndwrjj5yLWN1B4/bV0 6cRYRvZAIAWE6dSHRo/mLQfe9UAqfPHwdaitg27rWyPQ6nHBaD8+uVCxGyeI+XTB7zMR /Oz5+Bv9BY5mt4LCxg/jT5MT6Unl4mCdLTwNlUjdTFgjlDc5eoDLPJOMmMdSwWwIKypI 1SRCgwsg11UtV1z9sVfISm1XF/Sai+vnuGxM3cqvt7vv0ogEqBpw4bneDRgHKdeJujtU oOefq6L2Zn6QHzXfCZv4cM0bCZanJwoLzOoJbXjH2pROONmfQwWroofHFuRJMhxRULKA Sk4Q== 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=ftrYuJ10grD5ExsJhHz2A/aXRZAlBjgBaH79bs2PF48=; b=PTNNN8c2WmJXtb9G43hWRwguLR0SP1XOj0hfAO9Cr9zBoCBx23R9YWMjYo6EA4INdw LimkNYLr/bM+3ae1Fl8uqCB/L5jhwTZaLuE6CkyfBzCkpt22pKNU8vwvAm9K08iPEqmd JcpOwYdl55BAHvXwb/w/AJfJ4vQTGuj1ED9UzXH1s+NOnerm6Dq5M73LluQldd2ygwX3 vWPH+htnbmbZ3IuZbsIhyk5nZ7VaIxWwJvM+gHmCEzc+kNfsoVXoDLwurdTzl2w3o+ym evGJYTrDO/LM0i5PFZFWcgLlzXil1IDPUpbzhNiG9TsGCvPDOuhvr2+oNPzNZKm1W9J/ B8bw== 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=ftrYuJ10grD5ExsJhHz2A/aXRZAlBjgBaH79bs2PF48=; b=rR5FC7VhzkO1JgGxBe/P0qPNqdVQ93XA1xNr9khxHstzt1ygOKMt+krYgaGh89lgN3 fmUviWxtZ//gEF0uiAKhRdHWOXqs5aKT0zLB//QV92rrS3Urf+cc37p1PbQqtGORCZ5t iVYMwlLsXxxeiI7XZ5SiVv9FvdsDHRTQBCC22J5oBiuJRyypVlqDr+8IO4wsdgVN9HAc GPrraWgDsHex2QQ+w5DgiliOkQtUfpm5Cqb/hodHI1ag06NG2gqF8gTl6NRLoSg01wHi Z3npoHwGNffwzMnD/xhcgjAouxzP0g2VDlipWKkIPrCVapythDLhEw39CR2xVu9CIR1T 41Iw== X-Gm-Message-State: AOUpUlGf604k97OoNgujHssdaLjYVEJLBsfhhKmDviFWTiWvVALo6e5g YGr9lFd3Z43V+H5o8292GnuSxA== X-Google-Smtp-Source: AA+uWPyPdCkyA690UdVjzOeOpxa3w+JpQubM0aUyOvmnipF06FG2DERxhy+Gly0Idv7tKGlOlYDHtw== X-Received: by 2002:a81:82c5:: with SMTP id s188-v6mr14283863ywf.69.1534790704430; Mon, 20 Aug 2018 11:45:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:3b88:: with SMTP id i130-v6ls875367yba.6.gmail; Mon, 20 Aug 2018 11:45:03 -0700 (PDT) X-Received: by 2002:a25:4151:: with SMTP id o78-v6mr100170yba.4.1534790702965; Mon, 20 Aug 2018 11:45:02 -0700 (PDT) In-Reply-To: <89483da2-1435-49ef-94ea-d9d90fbac549@isocpp.org> X-Original-Sender: jmckesson@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:39938 Archived-At: ------=_Part_490_2044119226.1534790702057 Content-Type: multipart/alternative; boundary="----=_Part_491_1793215703.1534790702058" ------=_Part_491_1793215703.1534790702058 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, August 20, 2018 at 12:20:20 PM UTC-4, mihailn...@gmail.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= =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 Escrib= a=20 >>> 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 able= =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/tPtdQE2GXb= 0/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 dispatchin= g=20 >>>>> feature neither. >>>>> I'm just trying to separate the named parameter part from the overloa= d=20 >>>>> 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. >>>>> >>>> >>>> Can you elaborate a bit more, what are your expectations and where=20 >>>> should a line be drawn? As you can see in the comments to the post, th= ere=20 >>>> are similar concerns. >>>> In any case it is not a proposal, but an investigation. It is clear=20 >>>> tags have overlap with strong names, and if we can get an attractive= =20 >>>> proposition, based on tags, we can mark at least one part (the harder= =20 >>>> part?) of the named arguments equation "fixed".=20 >>>> >>>> I would like to see the two features proposed independently.=20 >>>> >>>> I see more added value for weak named parameters that are optional and= =20 >>>> opt in on the author side (as the workarounds are not always friendly)= than=20 >>>> the strong named parameters that can be used to overload function or= =20 >>>> constructors and that are not optional (as tag types are an almost fri= endly=20 >>>> library solution, as the standard library has showed already multiple= =20 >>>> times). >>>> >>> >>> The problem with having them be independent is that they're *not*=20 >>> independent. They're both playing around in the same space: invoking a= =20 >>> parameter's name when you call the function. >>> >>> The first question any named parameter proposal has to answer is whethe= r=20 >>> to rely on the existing parameter name infrastructure or to use a speci= al=20 >>> way to define them. There are arguments for both weak and strong parame= ters=20 >>> to want to have syntax to declare named parameters on a function. This = is=20 >>> because, by having users rely on them to some degree (even if mis-match= ed=20 >>> naming is just a warning), you are making those parameter names part of= the=20 >>> interface of the API. And that's different from how parameter names hav= e=20 >>> been treated in the past. >>> >>> I'm not for strong named parameters. For me, this is a disguised form o= f=20 >>> mixing weak named parameters and tag dispatching. This is why I believe= the=20 >>> features are independent. >>> Now you can put them together and obtain named parameters and tag=20 >>> dispatch. >>> >> >>> If you try to develop weak and strong parameters completely=20 >>> independently, then what you can end up with are two proposals that pro= vide=20 >>> completely different ways of declaring such parameters. And considering= all=20 >>> of the stuff that we keep cramming into function declarations these day= s,=20 >>> giving parameters *three names* is utterly absurd. Even if you forbid= =20 >>> weak parameter names on functions with strong names, that's still 3=20 >>> separate syntaxes for declaring parameter names. >>> >>> If we want weak and strong named parameters and don't see another=20 >>> solution than having two syntaxes :( >>> >> >> If that's the case, then we shouldn't have weak named parameters at all.= =20 >> Remember: weak named parameters are purely notational; they catch errors= ..=20 >> That makes them a "nice to have". Strong named parameters provide genuin= e=20 >> functionality, allowing you to express things that could not be expresse= d=20 >> before. >> >> If the design space is sufficiently constrained to only permit one or th= e=20 >> other, then it should be the one that actually does something. >> >> I don't believe that we want non op in named parametrs, so each one of= =20 >>> the weak/strong alternatives would need a specific syntax. >>> >>> >>> So I don't think it's reasonable to develop the two proposals completel= y=20 >>> independently from one another. They should at least be developed with = the=20 >>> knowledge that the other is a possibility, and with syntax that can=20 >>> reasonably fit together. >>> >>> Maybe you are right, but I would like that the proposal are clearly=20 >>> separated, so that we can be agains one from or the other. >>> >> >> So, you can't be against one part of a proposal? The standards committee= =20 >> does it all the time. >> >>> Lastly, it should be noted that tagged dispatch doesn't help with what = I=20 >>> will refer to as "mega-functions": functions that take stupidly large= =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 so= me=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 sett= ing=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 t= he=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 ar= e=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 defa= ult=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. >> > > 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 has= =20 no effect on function overloading. Essentially, if your rules require that all named parameter function calls= =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. --=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/333693b1-38a8-424f-bc15-0b36131b97f4%40isocpp.or= g. ------=_Part_491_1793215703.1534790702058 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, August 20, 2018 at 12:20:20 PM UTC-4, m= ihailn...@gmail.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.

Can you elaborate a bit more, what are your expectations and where should a line be drawn? As you can see in the comments to the post, there are similar concerns.
In any case it is not a proposal, but an investigation. It is clear tags have overlap with strong names, and if we can get an attractive proposition, based on tags, we can mark at least one part (the harder part?) of the named arguments equation "fixed".=C2=A0

I would like to see the two features proposed independently.

I see more added value for weak named parameters that are optional and opt in on the author side (as the workarounds are not always friendly) than the strong named parameters that can be used to overload function or constructors and that are not optional (as tag types are an almost friendly library solution, as the standard library has showed already multiple times).

The problem with having them be independent is that they'r= e not independent. They're both playing around in the same space: invoking a parameter's name when you call the function.

The first question any named parameter proposal has to answer is whether to rely on the existing parameter name infrastructure or to use a special way to define them. There are arguments for both weak and strong parameters to want to have syntax to declare named parameters on a function. This is because, by having users rely on them to some degree (even if mis-matched naming is just a warning), you are making those parameter names part of the interface of the API. And that's different from how parameter names have been treated in the past.
I'm not for strong named parameters. For me, this is a disguised form of mixing weak named parameters and tag dispatching. This is why I believe the features are independent.
Now you can put them together and obtain named parameters and tag dispatch.

If you try to develop weak and strong parameters complete= ly independently, then what you can end up with are two proposals that provide completely different ways of declaring such parameters. And considering all of the stuff that we keep cramming into function declarations these days, giving parameters three names is utterly absurd. Even if you forbid weak parameter names on functions with strong names, that's still 3 separate syntaxes for declaring parameter names.
If we want weak and strong named parameters and don't see another solution than having two syntaxes :(

If that's the case, then we shouldn't have weak named param= eters at all. Remember: weak named parameters are purely notational; they c= atch errors. That makes them a "nice to have". Strong named param= eters provide genuine functionality, allowing you to express things that co= uld not be expressed before.

If the design space i= s sufficiently constrained to only permit one or the other, then it should = be the one that actually does something.

=20 I don't believe that we want non op in named parametrs, so each one of the weak/strong alternatives would need a specific syntax.


So I don't think it's reasonable to develop the two proposals completely independently from one another. They should at least be developed with the knowledge that the other is a possibility, and with syntax that can reasonably fit together.
Maybe you are right, but I would like that the proposal are clearly separated, so that we can be agains one from or the other.

So, you can't be against one part of a pr= oposal? The standards committee does it all the time.
<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
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>

Are sure about that? Argument re= arrangement is doable without changing the signature (a.k.a. strong)
<= /div>

Maybe we have very different id= eas about what "strong named parameters" means. The question of &= quot;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.

--
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/333693b1-38a8-424f-bc15-0b36131b97f4= %40isocpp.org.
------=_Part_491_1793215703.1534790702058-- ------=_Part_490_2044119226.1534790702057-- .