220 39944 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: Tue, 21 Aug 2018 01:04:26 -0700 (PDT) Lines: 738 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> <371d2665-ee4b-4599-9d83-1d271312c5a8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1919_1883430474.1534838666602" X-Trace: blaine.gmane.org 1534838545 8910 195.159.176.226 (21 Aug 2018 08:02:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Aug 2018 08:02:25 +0000 (UTC) Cc: jmckesson@gmail.com, mihailnajdenov@gmail.com, bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBC4P57NQKGQEMPFVFJY@isocpp.org Tue Aug 21 10:02:21 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 1fs1cI-000273-De for gclcip-std-proposals@m.gmane.org; Tue, 21 Aug 2018 10:02:18 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id i15-v6sf9323699ybk.18 for ; Tue, 21 Aug 2018 01:04:29 -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=0uPFiFaFypDGie7vut3xpP+rYouRFHBYaJixtVcqVkg=; b=brUiTTWScsepkNGDopXeCFw1PYJN/+oq7t+Q5qoGDh9NzfcByZpf30a2lY+fgAtzIO EYEXlHfpa821bn3wEOub5SfqKSbEJ3XRiwo21XWQb94PzpMbI+YUJ9xFI/vACtqZaSuv //jihyQKF3/kDK/kj9TTgQjJADB2wMYrQpeT1VJKrsGYUINk5F3MkOuH7AOfs1qlnyNE IkoH4XaGOllzZTSOGUte8g1OeK8vovqw1sxvBiHA+yl4Xr292bEiT3ALTeVGvmrqQ6em NmbBBVlKiJ97AXsAf/om7/xcLN/jYPv4L1CX2TscWVsMW8dfiddwLvpZbojU8vUA0tvf 9Oqw== 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=0uPFiFaFypDGie7vut3xpP+rYouRFHBYaJixtVcqVkg=; b=ctVMz/7RMtIQilt7PIE+hNHGj5vGq2PZ/xt3Ry+ZN4JqRlebBJTg4VLvCJaiVYI9yt bLRIMH3Cm3YCnB1IEGbaxTrxdw4LC4n9a7RkeV2ZriBGJwBVuxHOFTOO2YdJS5UT07Pk MdHIR8QzdOvx55zjd7t5P96uBop4x5S70hWFQmY5K5FWLYtc26ZFvJXSeCtXYJJbehjk 806YFFNUgmTgiT357WZmJLr8+c+1pRaFLKj/Oo2bd3EMgieKKu7ST+NQyIVkHPGKws01 yWxoIH34lGOc7jDRKkucC5blz2Vs51NmCHoN9kknEHPfx13VxBjrVpjVpWXtpZmeWmpB l/lQ== 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=0uPFiFaFypDGie7vut3xpP+rYouRFHBYaJixtVcqVkg=; b=eiU1VjCQ48P2OaUKkflFvDidLL9jYDci+jeFyikW/dM9q7flb869QkjWoBfLMuvoQm nsPW+5RZUq3ZBv1nsqxvwspZYq1aytJP9jAXsYkPoJg0DNDrWWqpKyc9aPjhb35PnKQz jychdNq7vXoVGTHKl0/srSq1ULPo9tRfZTcwDrItQjwnFNlwbkRtl6vMXt6yRIlpOdjs 9K6I03jSmIw9BRsToX6T26NvR+WE4ZkH5NKL/6uEYH4V6AFVxI3HeTpORQCrGtxt92HV Kb0Hoffh8nxpUwSk1uqp9K3uQVFmLYgLA5J+TF0jl8hk2zTI/GK7cSrdVPBlGXIO0cEW 7VpA== X-Gm-Message-State: AOUpUlHJcUmO9qInm9XJOHGb5Zztc6ufpNY+n+Y9WtCRADqZITNBMe4H ZXU/OCZTywEvS0DvbkpHDzPhQw== X-Google-Smtp-Source: AA+uWPxPIl6u4rrKBWNU0PTXlIaYb/AZEwx++ATWg2nDiYjl0WrUVZiyxERIO0gczbsMoFHvNHZhpw== X-Received: by 2002:a81:6102:: with SMTP id v2-v6mr2441017ywb.119.1534838668761; Tue, 21 Aug 2018 01:04:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:888b:: with SMTP id d11-v6ls4370253ybl.1.gmail; Tue, 21 Aug 2018 01:04:27 -0700 (PDT) X-Received: by 2002:a25:4ec6:: with SMTP id c189-v6mr568308ybb.6.1534838667375; Tue, 21 Aug 2018 01:04:27 -0700 (PDT) In-Reply-To: <371d2665-ee4b-4599-9d83-1d271312c5a8@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:39944 Archived-At: ------=_Part_1919_1883430474.1534838666602 Content-Type: multipart/alternative; boundary="----=_Part_1920_1938981769.1534838666602" ------=_Part_1920_1938981769.1534838666602 Content-Type: text/plain; charset="UTF-8" On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, Nicol Bolas wrote: > > On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com > wrote: >> >> 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 >>> wrote: >>>> >>>> Are sure about that? Argument rearrangement is doable without changing >>>> the signature (a.k.a. strong) >>>> >>> >>> Maybe we have very different ideas about what "strong named parameters" >>> means. The question of "changing the signature" is not the distinction >>> between "strong" and "weak". At least, it's not the distinction that I'm >>> talking about it. >>> >>> "Weak named parameters" to me refers to named parameters which are all >>> of the following: >>> >>> 1. Optional. You can call a function that has named parameters without >>> naming the parameter(s) at the call site. >>> 2. Ordered. The order of the arguments must match the parameter order of >>> 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 no effect on function overloading. >>> >>> Essentially, if your rules require that all named parameter function >>> calls will 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". With 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 >> same way strong typedef introduces a new type. Everything else is weak as >> it is about the compiler not the code. >> > > That's not what you said earlier > > : > > Also, this obviously does not address the named arguments, *that are >> optional, the "weak" ones*, so this solution will not make everyone >> happy. >> > > Emphasis added. And there's this post > > : > > //weak argument names, not mandatory >> > ... >> > //strong argument name, adds an overload, not ignorable >> > > Yes, that post is talking about how you would declare weak names > differently from strong names, but it's also talking about how they get > used at the call site: "not mandatory" vs. "not ignorable". > There is no contradiction, they are optional, and ignorable by the user (he might not use them). Now, it depends on how much features they have, they might also be as weak as you assume they are, so they are (can be) ignored by the compiler as well and the call is the same. Most of the time here we talked about these weakest ones, and considered "extra features" as "bonuses". For me personally strong were always the one changing the signature, that's why the first post about tags-as-labels was called "Strong named arguments as tag overloads" And weak for me were not rearranging or skipping, but having defaulted-by-naming f(a:, b:, 10) Of course even these are not ignorable as the call will fail without them. Probably using the word ignorable was not correct. In any case weak names are optional. This is not to say, they do not affect overloading, they do, but only on the call site. void func(int a, int b); void func(int a, int b: b=1, int c: c=2); func(1, 3); //< overload 1 func(1, b: 3); //< overload 2 func(1, c: 3); //< overload 2 > Changing the signature is a clear boundary in both semantics and >> implementation. >> > But in the realm of non-changing-the-signature names, a lot can be done, >> granted the calls *will* differ w/ and w/o names. >> > > I think you're too focused on signature as the notion of a function's > identity. There are aspects of functions which are not their signature yet > directly relate to its identity. > > Return values. If you declare two functions with the same name and > signatures with different return values, then you get a compile error. > `noexcept` works that way too; you can't be inconsistent about that. Both > of these are part of the function's type, but not its signature (though > `noexcept` can be cast away). > > Contracts affect neither type nor signature, but even that requires some > basic consistency. You can declare contracts on a function or not. But all > contract declarations for the same function must be consistent. > > If a parameter name can be used as a syntactic modifier when calling the > function (for the purposes of this discussion, anything which affects > actual code generation. This includes reordering of arguments), then that > name ought to be, if not part of the function's type, then at least have as > much consistency as its contracts. That is, if you want to be able to > reorder parameters, then the function should consistently assign each > parameter a single name or a single "unnamed". > In the original post about weak arguments, I suggested they obey the rules of default arguments - you name your arguments only in the first declaration. No names afterwards, not even the same. auto child(name mother: mom, name dad); // auto child(name mother: mom, name dad); *//< error* // auto child(name mom, name father: dad); *//< error* auto child(name mutter, vater); *//< OK* auto child(name mother, name father) *//< OK* { // implementation } This seems the be the most consistent approach as (weak) named arguments ultimately inhabit *exactly* the same design space as default arguments - a compiler helper. With default arguments the compiler is only obligated to copy-paste the default expression if we don't pass a value. With names it is a matter of what features we want to have: - to only name-check - to paste in place of name-only - to paste on omission - to rearrange > If names can be inconsistent and still affect syntax, bad things result. > > Should it be done is a different matter, this is a debate as heated as the >> one about signature - some people consider names useless if they don't >> rearrange/skip defaults, some are happy with just checking alone. >> > -- 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/e6770d93-d3d7-464c-8414-2c5dfd07789d%40isocpp.org. ------=_Part_1920_1938981769.1534838666602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, August 21, 2018 at 4:52:56 AM UTC+3, N= icol Bolas wrote:
On Monday, August 20, 2018 at 4:18:34 PM UTC-4, mihailn...@gmail.com= wrote:
On Mond= ay, August 20, 2018 at 9:45:02 PM UTC+3, Nicol Bolas wrote:
On Monday, August 20, 2018 at 12:2= 0:20 PM UTC-4, mihailn...@gmail.com wrote:
Are sure a= bout that? Argument rearrangement is doable without changing the signature = (a.k.a. strong)

Maybe we = have very different ideas about what "strong named parameters" me= ans. The question of "changing the signature" is not the distinct= ion 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.

That's not what you said earlier:

Also= , this obviously does not address the named arguments, that are=20 optional, the "weak" ones, so this solution will not make eve= ryone=20 happy.

Emphasis added. And there= 's this post:

//weak argument names, not = mandatory
...
//strong argument name, adds an overload, no= t ignorable

Yes, that post is ta= lking about how you would declare weak names differently from strong names,= but it's also talking about how they get used at the call site: "= not mandatory" vs. "not ignorable".
=

There is no contradiction, they are optional, and ignor= able by the user (he might not use them).=C2=A0
Now, it depends o= n how much features they have, they might also be as weak as you assume the= y are, so they are (can be) ignored by the compiler as well and the call is= the same.

Most of the time here we talked about t= hese weakest ones, and considered "extra features" as "bonus= es".

For me personally strong were always the= one changing the signature, that's why the first post about tags-as-la= bels was called "Strong named arguments as tag overloads"

And weak for me were not rearranging or skipping, but hav= ing defaulted-by-naming f(a:, b:, 10)= =C2=A0
=C2=A0
Of course even these are not ignor= able as the call will fail without them. Probably using the word ignorable = was not correct.=C2=A0

In any case weak names are = optional.=C2=A0
This is not to say, they do not affect overloadin= g, they do, but only on the call site.

void func(int a, int b);<= i>
void func(int a, int b: b=3D1, int c: c=3D2);<= /font>

func(1, 3); //< overload 1<= /div>
func(1, b: 3); //< overload 2
func(1, c: 3); //< overload 2<= i>
<= i>

Changing the = signature is a clear boundary in both semantics and implementation.
But in the realm of non-changing-t= he-signature names, a lot can be done, granted the calls will differ= w/ and w/o names.

I think you&= #39;re too focused on signature as the notion of a function's identity.= There are aspects of functions which are not their signature yet directly = relate to its identity.

Return values. If you decl= are two functions with the same name and signatures with different return v= alues, then you get a compile error. `noexcept` works that way too; you can= 't be inconsistent about that. Both of these are part of the function&#= 39;s type, but not its signature (though `noexcept` can be cast away).

Contracts affect neither type nor signature, but even = that requires some basic consistency. You can declare contracts on a functi= on or not. But all contract declarations for the same function must be cons= istent.

If a parameter name can be used as a synta= ctic modifier when calling the function (for the purposes of this discussio= n, anything which affects actual code generation. This includes reordering = of arguments), then that name ought to be, if not part of the function'= s type, then at least have as much consistency as its contracts. That is, i= f you want to be able to reorder parameters, then the function should consi= stently assign each parameter a single name or a single "unnamed"= ..


In the origina= l post about weak arguments, I suggested they obey the rules of default arg= uments - you name your arguments only in the first declaration. No names af= terwards, not even the same.=C2=A0

auto child(name mother: mom, name dad);=C2= =A0

// auto chil= d(name mother: mom, name dad); //< error
//
<= /span>
auto child(name m= utter, vater); //< OK=
auto child= (name mother, name father) //< OK
{=C2=A0
=C2= =A0 // implementation
}
=C2=A0
This seems the be the most consist= ent approach as (weak) named arguments ultimately inhabit exactly th= e same design space as default arguments - a compiler helper.
With default arguments the compiler is only obligated to copy-p= aste the default expression if we don't pass a value.

With names it is a matter of what features we want to have:
  • to only name-check
  • to paste in place of name-only
  • to = paste on omission
  • to rearrange



    • If names can be inconsistent and still affect = syntax, bad things result.

    Should it be done is a differe= nt matter, this is a debate as heated as the one about signature - some peo= ple consider names useless if they don't rearrange/skip defaults, some = are happy with just checking 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/e6770d93-d3d7-464c-8414-2c5dfd07789d= %40isocpp.org.
    ------=_Part_1920_1938981769.1534838666602-- ------=_Part_1919_1883430474.1534838666602-- .