220 39850 article Path: news.gmane.org!.POSTED!not-for-mail From: Justin Bassett Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Thu, 16 Aug 2018 21:29:50 -0700 Lines: 206 Approved: news@gmane.org Message-ID: 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="000000000000561b1605739a03cf" X-Trace: blaine.gmane.org 1534480081 18605 195.159.176.226 (17 Aug 2018 04:28:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2018 04:28:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5PL3NYWEDBBSU63HNQKGQEFAKNIUQ@isocpp.org Fri Aug 17 06:27:56 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqWMa-0004cO-S0 for gclcip-std-proposals@m.gmane.org; Fri, 17 Aug 2018 06:27:53 +0200 Original-Received: by mail-oi0-f71.google.com with SMTP id e23-v6sf6187089oii.10 for ; Thu, 16 Aug 2018 21:30:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534480203; cv=pass; d=google.com; s=arc-20160816; b=a1InVboHYrS87I1HVR4U4oPhxMxz2EaLfBraEeEPWMRJDjcEdxRfB4BekCVPTp5mhu nzRHFUrn74XM0xPD4ZQ/aFoUsklsKXTX+dL04pOkDoqolI2aoOKT48BJTdKyjDsdf6I2 SL3Mhmhjbjw/aX+jv/yxbuXpRmGqRkwuOwxvMNbNkFHEHH8ANMaFbyhkGdjIkSVPbynH l6ZvhmHW3LaPdYzjzYhkZ76tnJqMO+rVKPxDWSoBkpm/uDPlUZAQb9u7rgBj4A4JGlqN R2tYpQSupsJ9TeqiY6I2CFv9+GQmUfuHMKCVX8Iz9KOfHQlIlpULuBstKK30cahThLQA Ks+Q== 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:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=jJVtVs8N/SWevYxU77/E65opj5wOaBzwd9+OwO1C4D8=; b=ObL5lrZxY7yEYqPZ2SoM3qISksFuBvPxyMpDHmFjKoNKXtH1l0y6ip0zd7Mn2Du6Hd R1pemSJeQod8mKdi2xAZ/XnJhV1YVLau8JHJyZsOZ8T0BR3KV9mMTGBjpI0VbSc1zNut N7AzFNsYsc2Sg08yBHeB0vszopqZRhDQxaHwt+OBAK8TOuRH28umbR4NdwBKWH3JFifD Wmn7XdFsaQGLWbnnOoyz+WbOGyOpyPP0+BxGUyPpTKuyxAMl6B4NYnfdqF6LxWlBKeYg l1Nr6CZ6zzyscbKwEwYkMCeNkF8WcB6/hNEfdGR7B4PzzsrJBDamYSrU0RncWaCIKG3Z AZ2w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mqozbY+9; spf=pass (google.com: domain of jbassett271@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jbassett271@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :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=jJVtVs8N/SWevYxU77/E65opj5wOaBzwd9+OwO1C4D8=; b=NBKVMt/bv0j2nX7UxRRAfDMZZ8pUdmZwiEQmp0hE5CEhfS7q/QSRgOc+inhQShBk7E fWkC4auER46S0alucjtt9buAubm+nneMBfW0vneYMOIrs4Z3y2XYOZz3/i9tHrOqwhSf QveP/s2WHowS1k7V3TBRs1YO0/DOPtiaA96Etw24Ing1BA4dINcjFqXkXmGIVcffZgaZ W5oxb6qCPZUwd35PHsaxYPnP4G+BrpNOhUcAdD9nAelEsaqw1yMi6CL/tZcQasyUEYxh I/XEMBi+7xRaGVUo/JmGr8L1ztkNKEPb1mbyNpI4W1cfFGQWWdIOt4LavdNo8Qb8FRqQ Y2zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to: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=jJVtVs8N/SWevYxU77/E65opj5wOaBzwd9+OwO1C4D8=; b=GvU87jDqZCKyn/7VksQ8Ipf5/iOONyK4bz9JfKCXRf7iHesanS5e8ZZt2TDB8aiFfo BcxLydcUUp657LdBsmg3+pOY/rSdVPwU95PaDyC7T0Metz04i8DZwXc0ofCwBn/07dh5 4ML9pN1CR3qVQFuyyi4mx7IDrEQ0WPf4T0Gf2baTmIvxdt+1L87emha4H77epLbCgPYM S77WUkJ82WAdhUG5QThaXBCUtgqgo/cHx3B96g+rhAGEmnIxGpvS4bOH14gxwvwMaHF1 k/rZ405h6fiBaa7m62e40DnYSJu0+geylpN5bAaeQEaTE4BKCmNt05UwoBPIH3PCQmhm OzXg== X-Gm-Message-State: AOUpUlGq6ygPXF1ozls+/GVSkw/V62tvHR2qRLG7YqrN6tbt2uwi2GGq yqscehkG6+jngxWbaiULoXg1Ig== X-Google-Smtp-Source: AA+uWPxSZQ5l0ZJzJqKEdlzXqdx+PHso5Xu1JmluzVUu0DYo+M/RMedbiJ2cTPPWLPjs/d36A+kadQ== X-Received: by 2002:aca:e583:: with SMTP id c125-v6mr19154246oih.99.1534480203142; Thu, 16 Aug 2018 21:30:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:aca:5096:: with SMTP id e144-v6ls3822844oib.14.gmail; Thu, 16 Aug 2018 21:30:02 -0700 (PDT) X-Received: by 2002:aca:5c85:: with SMTP id q127-v6mr801922oib.127.1534480202139; Thu, 16 Aug 2018 21:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534480202; cv=none; d=google.com; s=arc-20160816; b=eq0PsYdg7LPuyPnwY3QEt102Eo0ln6BLPKfTJl7dlOMS7pgRyZIuaY7L0bJhogcLCs s/wc0ujfvyr2q51eB3fjt07p4sIzFmt1yvC/AmLllQmpJfDjjVFn8Vb2KsTrebpwK/nZ FgVYPJjaeypJfqPZ/cJLlZNwkY2YHAoZ87DVz96XSP3mN2PxUUKkLydsUOTJPQ5onEUP 6D9GWBhRXQANf4ikdpnIH0i9eWTtVaCsE2AQ5COWqa9szME3v28B2pBMVOLxiv5D1J8l kNudlNXC0qX+jG6rmDXXND0uNJMTL1SYFuWsf7UmakxWXIdo62z1otV3sL+uitaNekZm sTWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=XHyodFrNY9OPuwzBrq2T6DINJ0zdd1HNUijx+h79RSA=; b=ahNygdVexd8ubafpY1Nkm9j3x5CKEVYphkGJb6gsdXFGxiSl2+IeUHNrbU76HoouuC 41aCyCtgunEBfxkwzJ6A+uCSeNANffu/+pioYB5KfGxxLtuL5p83xmcWcrF/oXZbiRcC osSHlijuzwf7l/3a58pG9UzAmYgapI2gRmQ0D7C3PZC3sWg2TOii1Dygz4brWNKo9Ikp 5Htm2wcT8SKzibH9Ra8+rbSFRbNQ4d2tviLQtBlxzyQNDlkwfWH7nvYESnSONB7IEkOn QVX8zfBn6IXwFh6aXjLJs9Ow9Rdg550j3rop3MefJuknIDuwNL9MnpnLnB5LAZ+2xgi8 shFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mqozbY+9; spf=pass (google.com: domain of jbassett271@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jbassett271@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id e72-v6sor599857oih.18.2018.08.16.21.30.02 for (Google Transport Security); Thu, 16 Aug 2018 21:30:02 -0700 (PDT) Received-SPF: pass (google.com: domain of jbassett271@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:aca:e504:: with SMTP id c4-v6mr827779oih.246.1534480201684; Thu, 16 Aug 2018 21:30:01 -0700 (PDT) In-Reply-To: X-Original-Sender: jbassett271@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mqozbY+9; spf=pass (google.com: domain of jbassett271@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jbassett271@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:39850 Archived-At: --000000000000561b1605739a03cf Content-Type: text/plain; charset="UTF-8" Clicked send a bit fast. Strong types and named parameters are not replacements for one another. They solve different classes of problems. Strong types don't handle the case of providing a value for a parameter in the middle of a bunch of defaulted parameters. Operator overloading is not a good solution. You need to namespace qualify everything (else using), and it abuses operators in a way that makes it unclear what's going on, especially when using operator=. Boost Graph's named parameters are the best calling-side API I've yet seen for named parameters. It is not nice to maintain code that provides such nice APIs, though, although one could make a library to make it more reasonable. Tag dispatch is orthogonal to named parameters IMO. Using tags such as std::in_place is just a way of saying, "I know this is an overload set, but I really need to call this particular overload." That's not naming parameters, that's naming overloads. Tag dispatch would not work for Boost Graph's use case, which is approximately option 4 that Henry Miller mentioned. On Thu, Aug 16, 2018 at 9:23 PM Justin Bassett wrote: > > > 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 = value) by overloading > operator=, 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 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. > 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. > > 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. > > Designated initializers fall short if you go more than one layer deep: std::invoke(something_with_named_parameters, > { .arg1 = 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. > > 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 > more than a few optional parameters, it becomes unreadable fast: foo(123, > nullopt, nullopt, "string", nullopt) > -- 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/CAPuuy5cV03gX4Th%2BLxPAAXjnBEyNatrdinrjVFRLsSiLavj%2BjA%40mail.gmail.com. --000000000000561b1605739a03cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Clicked send a bit fast.

Strong types a= nd named parameters are not replacements for one another. They solve differ= ent classes of problems. Strong types don't handle the case of providin= g a value for a parameter in the middle of a bunch of defaulted parameters.=

Operator overloading is not a good solution. You = need to namespace qualify everything (else using), and it abuses operators in a way that makes it unclear w= hat's going on, especially when using operator=3D.

Boost Graph's named par= ameters are the best calling-side API I've yet seen for named parameter= s. It is not nice to maintain code that provides such nice APIs, though, al= though one could make a library to make it more reasonable.

<= /div>
Tag dispatch is orthogonal to named parameters IMO. Using tags su= ch as std::in_place is just a wa= y of saying, "I know this is an overload set, but I really need to cal= l this particular overload." That's not naming parameters, that= 9;s naming overloads. Tag dispatch would not work for Boost Graph's use= case, which is approximately option 4 that Henry Miller mentioned.

On Thu, Aug 16, 2018 at= 9:23 PM Justin Bassett <jbasse= tt271@gmail.com> wrote:


On Thu, Au= g 16, 2018 at 12:02 PM Nicol Bolas <jmckesson@gmail.com> wrote:
I think that there should be a discu= ssion 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 perhap= s 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(p= arameter =3D value) by overloading operator=3D, sometimes done with other operators instead); I beli= eve 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))
  • The named parameters idiom and Boost Graph's named para= meters both require a lot of overhead on the library author's side. The= re's a lot of code that needs to be maintained. If you want to prevent = parameters().foo(value).foo(some= OtherValue), that's = even more work. Together with designated initializers, I've heard that = this can also produce worse codegen, since we are passing around a struct r= ather than individual parameters.

Strong types and designated initializers fall short in par= ameter reordering. Sure, you can provide all possible combinations with str= ong 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 f= or named parameters. Also, it's annoying to use without using declarati= ons or directives.

Desi= gnated initializers fall short if you go more than one layer deep: <= font face=3D"monospace, monospace">std::invoke(something_with_named_paramet= ers, { .arg1 =3D value }). You have to specify the name of the struct, which is jarring. It's a= lso not nice to decompose elements of each struct to send them into other n= amed-parameters-designated-structs. I was convinced designated initializers= would be the solution to C++'s lack of named parameters, but I ran int= o problems such as this when experimenting with it. I had some more complex= scenarios, but I have since forgotten them.

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

This isn't= named parameters. This is optional parameters. Once you get more than a fe= w optional parameters, it becomes unreadable fast: foo(123, nullopt, nullopt, "string", nullopt)= =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/CAPuuy5cV03gX= 4Th%2BLxPAAXjnBEyNatrdinrjVFRLsSiLavj%2BjA%40mail.gmail.com.
--000000000000561b1605739a03cf-- .