220 39854 <81d3b2f3-398f-9ac2-1783-074ac2ad1ef5@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Fri, 17 Aug 2018 11:22:40 +0200 Lines: 322 Approved: news@gmane.org Message-ID: <81d3b2f3-398f-9ac2-1783-074ac2ad1ef5@wanadoo.fr> References: <1534441498.3721109.1476442920.71D445BF@webmail.messagingengine.com> <12ca0430-f790-4dee-b491-266435bae170@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AE29460FE2077455583A711E" X-Trace: blaine.gmane.org 1534497638 12185 195.159.176.226 (17 Aug 2018 09:20:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 09:20:38 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 To: std-proposals@isocpp.org, Justin Bassett , =?UTF-8?B?0JzQuNGF0LDQuNC7INCd0LDQudC00LXQvdC+0LI=?= Original-X-From: std-proposals+bncBDH67CONY4PBBYNH3LNQKGQERXUFSAQ@isocpp.org Fri Aug 17 11:20:33 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr1-f71.google.com ([209.85.221.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqavn-00030d-N6 for gclcip-std-proposals@m.gmane.org; Fri, 17 Aug 2018 11:20:31 +0200 Original-Received: by mail-wr1-f71.google.com with SMTP id t5-v6sf5291705wrq.14 for ; Fri, 17 Aug 2018 02:22:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534497762; cv=pass; d=google.com; s=arc-20160816; b=IvLhlWtl9UsRK73+73sR+va/PmDrv5K7tX1IlWGJ8xMUKQKE3j3cMoDb5k5Ekbw1oJ XhkpuzrZ1p3bVMfcXgE7/5Cv29GWndpnMFEjWA1YURbkH/WH6apBfFjlzAYuNPUruPD1 3zPacBGD4ekuTMspkuX1iIpIpoSRyDE2WLrnxusZDmsmMKmnwzejqfGeqt6I06/1ILOw Jl5yStTkOeUyKLo6L9+iWsjYAyXFKNKu3VgKpEIrnWeaJZ8VUphNNAkXZ3OJM+40BDiO AN65Ki6gQsAQNaTb6aHuTFRHJhlTBhrOLoCjn6rEfgtepN8xoZMN5LlRn0XCWLr8BLA7 VkAw== 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 :to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=tXhGVEBUlPqo/SXSZk7HAqYZY0z5QnSRL+f4CWLdi0g=; b=EaGxiqchiEZnM685Htt1tou0LKHfsHXhhkZDB14liuVJpTlJD0xPpqdhrnVaNXF4d1 /H+W2DwOL8x01QvxeNt4h68Q7tMCaeWJtGTVvc0GnM+IaG11jEbzbHsf4U/L7fqRZD+7 MwizeXfxLhhATXbHzOgMEXuCDd9gIpMRQGtkPn6oUzP6Pk6MLCIVRYnB0cwQtl7VWUsb iwWBDy+8K3DrQrDqAs2gEhEKsw0BqIhJLGBrgKd7ToulK3NmwoBhyPXN6xEuLcDIxwff pSEMKF2LP2l5ZxuUrCLt3p6eqov85zpVb/iXawmwucskgmxDL/ppgsopng5PC5riCBVK sPNA== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to: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=tXhGVEBUlPqo/SXSZk7HAqYZY0z5QnSRL+f4CWLdi0g=; b=kjAWgunl80yuYSYNceveNWPK5mRMGzsnPFtSvKPtY7Ho4eIozRCwUOdookTvszTiSU htoSe/ubrjGCbRdVtv4BC/iiSyaLFJlI0pDqz3ddlmoU+c9J83GrKsOsrNxm3/mMYd8z +GPSbpOA2qgi3B1wlt4DUZMWDlkTugPMDFuCAbXBVDHQshW68kYwU61KlCTqDtHpSkxx SpNiD7Pd8L3FRpHhXeS4J3i+28vq8Z5XeTA1Sfu4KAt9IConHwC/HXdwTiVjOyYDhYy6 1W+lUHEskx0x4ep35JPC5RRyQJnYGNf+AkigF2nA/lfbOm8pr1qJLtqLzSJ4EYOcyIG/ CPxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to: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=tXhGVEBUlPqo/SXSZk7HAqYZY0z5QnSRL+f4CWLdi0g=; b=fuGXNGRWC+NACUAqWWKVfadoGhwONfwaC+XpQi948jCfGTI3lzRWxxHV0WJRNx3Gc7 xlls4NAlpk7ynPwLyXopIkwYdjHYEuYCt/Jq/0dej7xPwW7JMBW4NXWmSWpRslbDkriJ ZRZDsaSRed0C5oRxZPdKtpUCYoiCbpv3+PXmTl58YWd5FZb/fUebCW4CTVQ2XpHLw6hu abjms2cHpZknoFCUwy8TUlR6j53281zfpU/a8qM73wMg5M/Q7K+9ts3XWlTzXbCnJdPF 2/jr3QNsiseUaINkSUJVwAQA4FblloynP//+IrhWSX+jlu23fxxwc6KDOyykNMj5lV+2 e X-Gm-Message-State: AOUpUlG2YpLYrVt0sN+2SEfkmccdd1mbRbWJZcCTqnsL0tmmTmgZE6gu k03JJL32EpXgsTBfsOenidM= X-Google-Smtp-Source: AA+uWPx/tQ2HbWamxnxiCISgNwXXylgJ/zqf0l8/eET1LBsGFACky00AHIjWch5RBc1bfmwptJwNEA== X-Received: by 2002:a1c:ca0b:: with SMTP id a11-v6mr2418983wmg.17.1534497762370; Fri, 17 Aug 2018 02:22:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:e38b:: with SMTP id e11-v6ls2036112wrm.5.gmail; Fri, 17 Aug 2018 02:22:41 -0700 (PDT) X-Received: by 2002:a5d:528f:: with SMTP id c15-v6mr21604779wrv.102.1534497761366; Fri, 17 Aug 2018 02:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534497761; cv=none; d=google.com; s=arc-20160816; b=eqS+xiI0SsZvL4DM3MdqWHDXdbbw3zKTBLCTCSg0u38yEAbua5iMYVXTcmTnvZy5/A EUqFO51pYOrtKnEwDfRLUMP8iR4G+WTgotby7v5CcPygLwr2rPWF7LqqckJp40qSq5p4 X1VaYC9gfiaXWm+XCxqdYAHpKdA6qd+AVwB/1y8aMYhiWOIVd4/GIdoLycFvLWG1byaf 6mK1lFs0u4bwELj/WjH/G7iW3LI4kiu4+H31R02/ThvAOzT6h9l5ZVHNj0LB/eHma0cA /al9zqmbawJoT7lXcqQz7F1FqvD8TPCM/Hj+rJryAG4d2gJCfi1viqrQ9e9J9JuVxEeQ 4G5w== 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:to:subject:arc-authentication-results; bh=dCMJzo/W8OoBi3jVhrp5yOIsjxyh+5bA7fR0p9GTF98=; b=tXATce/G4R8u8C6PsvyK1qnKcN+22SwADoQBkYTr4p3v/qTMHNdCbghN+e2Mofw+G+ lS44/jc6isVfFfm2QTHhhI6y4puFBuNppqbQ0Rgs+8AUGNv24rp8JNqtadDK2arHPtiW g6ZAd50mEigrsqig6smApc6BTIOXDpn2n8YnuN0NBQPU1ntGiQB44VofPUF2v6BL3zhb 9iA7dhDU7OhYiDJ7kc1jJr1PYC94yz4moarZiZKVRPWQmjfBLy0BUeUg3PZ7qcz0iYpu rmj3UIw0dFgk4b62XFXbGqQMVe8i5yZK+gbKBO6eftmN/DKIT8SsOpTVKXWbGLQ7WfVl SXGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr. [80.12.242.133]) by mx.google.com with ESMTPS id p8-v6si1367875wrc.411.2018.08.17.02.22.41 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 17 Aug 2018 02:22:41 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.133; Original-Received: from imac-de-vicente-botet-escriba.home ([86.253.39.2]) by mwinf5d46 with ME id Q9Ng1y00B02nUfq039Ngh9; Fri, 17 Aug 2018 11:22:41 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 17 Aug 2018 11:22:41 +0200 X-ME-IP: 86.253.39.2 In-Reply-To: Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:39854 Archived-At: This is a multi-part message in MIME format. --------------AE29460FE2077455583A711E Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 17/08/2018 =C3=A0 06:23, Justin Bassett a =C3=A9crit=C2=A0: > > > On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas > wrote: > > I think that there should be a discussion of existing solutions to > all of the problems of interest, so that we can enumerate why > those solutions are not good enough. It would also allow us to > perhaps find a better way to handle this than with named > parameters. For example, if tagged dispatch solves a lot of these > problems, then perhaps we can incorporate tags into the language > in some more formal way rather than going to full named parameters. > > > A short list of current solutions I know of: > > * "Named Parameters Idiom" > * Strong types > * Tag dispatch > * Operator overloading (writing foo(parameter =3D value) by > overloading operator=3D, sometimes done with other operators > instead); I believe Boost Parameters does this > * Boost Graph's named parameters. The named parameters argument is > always the last and is specified by member functions. Similar to > the named parameters idiom, but more complex: > boost::foo(positional, arguments, boost::arg1(val).arg2(val2)) > * Designated Initializers > > The named parameters idiom and Boost Graph's named parameters both=20 > require a lot of overhead on the library author's side. There's a lot=20 > of code that needs to be maintained. If you want to prevent=20 > parameters().foo(value).foo(someOtherValue), that's even more work. I guess for you the named parameter idiom is what Boost.Parameter=20 provides, isn't it? > Together with designated initializers, I've heard that this can also=20 > produce worse codegen, since we are passing around a struct rather=20 > than individual parameters. I heard the opposite about the performances of designated initializes=20 ;-) I suspect that it will depend on the particular case. We need=20 concrete cases and measure. > > Strong types and designated initializers fall short in parameter=20 > reordering. Sure, you can provide all possible combinations with=20 > strong types, but then it becomes unmaintainable. Strong types also=20 > require a type for each name you wish to use (if you want different=20 > types, that works within C++17's CTAD), which might run into problems=20 > if you end up with collisions with names of actual types rather than=20 > psuedo-types made just for named parameters. Also, it's annoying to=20 > use without using declarations or directives. I don't want to use strong types to solve the problems named parameter=20 is intended to solve as I don't want to use named parameter to solve the=20 problems strong type intend to solve. > > Designated initializers fall short if you go more than one layer deep:=20 > std::invoke(something_with_named_parameters, { .arg1 =3D value }). You=20 > have to specify the name of the struct, which is jarring. It's also=20 > not nice to decompose elements of each struct to send them into other=20 > named-parameters-designated-structs. I was convinced designated=20 > initializers would be the solution to C++'s lack of named parameters,=20 > but I ran into problems such as this when experimenting with it. I had=20 > some more complex scenarios, but I have since forgotten them. perfect forwarding will imply to have specific function types or to use=20 overload sets. For me named parameters don't change the function type (let me know if=20 this is something you want). This implies that named parameters couldn't=20 be used to solve this perfect forwarding issue. You need tag dispatching=20 or something else. There is a proposal (from Mihail), that associates some named parameters=20 to the function type. I believe that we need to name it differently. I=20 will consider the first named parameter as as syntactic sugar for tag=20 dispatching ,ad the other just named parameters. As the nature is=20 different I would like to have different syntax for the parameters that=20 change the signature and those that don't change it. > > There is also the option of using `optional`. So you'd > call it with `foo(nullopt, 1234)`, and allow the internal code to > fill in the default. This alternative also has the advantage that, > if the default changes, you /don't have to recompile/ to get the > changed value. Named parameters could take advantage of that too > by using `optional`. > > > This isn't named parameters. This is optional parameters. Once you get=20 > more than a few optional parameters, it becomes unreadable fast:=20 > foo(123, nullopt, nullopt, "string", nullopt) I agree. Vicente --=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/81d3b2f3-398f-9ac2-1783-074ac2ad1ef5%40wanadoo.f= r. --------------AE29460FE2077455583A711E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 17/08/2018 =C3=A0 06:23, Justin Basse= tt a =C3=A9crit=C2=A0:


On Thu, Aug 16, 2018 at 12:02 PM Nicol Bolas <jmckesson@gmail.com> wrote:
I think that there should be a discussion of existing solutions to all of the problems of interest, so that we can enumerate why those solutions are not good enough. It would also allow us to perhaps find a better way to handle this than with named parameters. For example, if tagged dispatch solves a lot of these problems, then perhaps we can incorporate tags into the language in some more formal way rather than going to full named parameters.

A short list of current solutions I know of:
  • "Named Parameters Idiom"
  • Strong types
  • Tag dispatch
  • Operator overloading (writing foo(parameter =3D value) by overloading operator=3D= , sometimes done with other operators instead); I believe Boost Parameters does this
  • Boost Graph's named parameters. The named parameters argument is always the last and is specified by member functions. Similar to the named parameters idiom, but more complex: boost::fo= o(positional, arguments, boost::arg1(val).arg2(val2))
  • Designated Initializers
The named parameters idiom and Boost Graph's named parameters both require a lot of overhead on the library author's side. There's a lot of code that needs to be maintained. If you want to prevent parameters().foo(value).foo(someOtherValue), that's even more work.
I guess for you the named parameter idiom is what Boost.Parameter provides, isn't it?
Together with designated initializers, I've heard that this can also produce worse codegen, since we are passing around a struct rather than individual parameters.
I heard the opposite about the performances of designated initializes ;-) I suspect that it will depend on the particular case. We need concrete cases and measure.

Strong types and designated initializers fall short in parameter reordering. Sure, you can provide all possible combinations with strong types, but then it becomes unmaintainable. Strong types also require a type for each name you wish to use (if you want different types, that works within C++17's CTAD), which might run into problems if you end up with collisions with names of actual types rather than psuedo-types made just for named parameters. Also, it's annoying to use without using declarations or directives.
I don't want to use strong types to solve the problems named parameter is intended to solve as I don't want to use named parameter to solve the problems strong type intend to solve.

Designated initializers fall short if you go more than one layer deep: std::invoke(= something_with_named_parameters, { .arg1 =3D value }). You have to specify the name of the struct, which is jarring. It's also not nice to decompose elements of each struct to send them into other named-parameters-designated-structs. I was convinced designated initializers would be the solution to C++'s lack of named parameters, but I ran into problems such as this when experimenting with it. I had some more complex scenarios, but I have since forgotten them.
perfect forwarding will imply to have specific function types or to use overload sets.
For me named parameters don't change the function type (let me know if this is something you want). This implies that named paramete= rs couldn't be used to solve this perfect forwarding issue. You need tag dispatching or something else.
There is a proposal (from Mihail), that associates some named parameters to the function type. I believe that we need to name it differently. I will consider the first named parameter as as syntactic sugar for tag dispatching ,ad the other just named paramete= rs. As the nature is different I would like to have different syntax for the parameters that change the signature and those that don't change it.

There is also the option of using `optional<double>`. So you'd call it with `foo(nullopt, 1234)`, and allow the internal code to fill in the default. This alternative also has the advantage that, if the default changes, you don't have to recompile to get the changed value. Named parameters could take advantage of that too by using `optional`.

This isn't named parameters. This is optional parameters. Once you get more than a few optional parameters, it becomes unreadable fast: foo(123, nullopt, nullopt, "string", nullopt)
I agree.

Vicente

--
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/81d3b2f3-398f-9ac2-1783-074ac2ad1ef5= %40wanadoo.fr.
--------------AE29460FE2077455583A711E-- .