220 39839 <1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Henry Miller Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Thu, 16 Aug 2018 15:41:45 -0500 Lines: 350 Approved: news@gmane.org Message-ID: <1534452105.3767720.1476682240.226BF14C@webmail.messagingengine.com> 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="_----------=_153445210537677200" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534451983 4820 195.159.176.226 (16 Aug 2018 20:39:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 20:39:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQPBM7KRMDBBC6D27NQKGQEXDCV3KY@isocpp.org Thu Aug 16 22:39:39 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqP3S-00019b-Ee for gclcip-std-proposals@m.gmane.org; Thu, 16 Aug 2018 22:39:39 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id m2-v6sf5651506qka.9 for ; Thu, 16 Aug 2018 13:41:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534452108; cv=pass; d=google.com; s=arc-20160816; b=qKYGxnknyyqEboDX/nyvxKct6AtfPUgGEEGGY1mt59j7sZdJrXWl19eAkCbtnEqTQ0 92QtdzI6Hf86/bwiWXvMjmFV/fh+fRTipTOQi8hr8dkRFB1JXw90xwu1BeNeDWsE1od4 cL2W7hhvOe75dPGdpSdDQOxVuoqO4srllVn60B1tRYBKEwO1MbpjHzrtYXzLnhHakMA9 xzZyXYnYQSJgyzdyifuN4wIgCHBkt3DhU4Q/pUGxhnXhEM18ZppGdiT+WW4on+DdM12X 0kRUTB3gKv3RAkZYhnPF0ek3qJdg3pJPUdn2+i+oDrexpTv5vsITz66KZBx+6jRJcPbz 3oHw== 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:in-reply-to:references :subject:date:content-transfer-encoding:mime-version:to:from :message-id:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=9wlyrFv2VMqHUAiYBrawjwcqNzNoBPE+o9n1//6HCGM=; b=iZdC26nUjSwYIQZUnsCrysX0tHjS2qVvJKKy36etj02uiJHDJoPmv2EtlP2SHU49HO 6Wa3xqAoS+KV60l6nk+XfKcX1PXynsAKUAqPiQsM5luSuPq/9Lzne8JEVRGsNUj0ThAD 8PE25PSGBgAZmMhDKFbAwOSOT+r/GV1YsAiPPgneTY7P6rFEvpzguUYmALkp2dAMZugi udbG/RcEK4cXHtlvBuI3+k2OLw53AmDu7iWMZIzVlAhBOxphSc2/jIRndHmb9emMHH6T 6D/e23H2lR+Cx9Xfr8aLk8erAg01Ex80nJMQ1+hEETaOFJMsvptbAkeXghzX+fSaWbmw i8qw== ARC-Authentication-Results: i=2; mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=sRh74+0c; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PWwpiCNT; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=message-id:from:to:mime-version:content-transfer-encoding:date :subject:references:in-reply-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=9wlyrFv2VMqHUAiYBrawjwcqNzNoBPE+o9n1//6HCGM=; b=fG1VPXWp6Yspc+te1du+a0jLxZwm/KyJVog1heiO9T/fikD1vV1s6//mdb8f+CO0OV K7TEpWfIu2qX95CHavZ8PDMNBdAmcImSk459AkSEu4JoVFA7uhMQbN4SSu2q5A90PcQZ 81TFpwkLsrhCce9DeZcr0yTlYXZ8mfNljfFtvbKXto8lKO95lwLSBcu6bpEGufTr51op Lgm8CaBFBQu6pVK6WkimSUoRJAnjEJkyrQZRyPRW99MtdjGm5zkIzobjolSGG7LZ6bRp 4fCE6kZXKoCyT8zTvjeQq5vQGXQAm/FkfybJRTTTDzNqWlRjgMRf4kXaxbkw/ejju3oO iDFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:mime-version :content-transfer-encoding:date:subject:references:in-reply-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=9wlyrFv2VMqHUAiYBrawjwcqNzNoBPE+o9n1//6HCGM=; b=pchvj/obf2kA3FPBT8rm1f8mXRe3ZEdL08jRs6BoNb1d00OpnduP37WQsxA3dN6xJt /k5Xc3+NOZgPBa8sR33AAvFiM/9r8aZayHXgWXxCu5bZb/dg/RGGJSwd1Kh3IeqRUbtF 2vY8Ye9EIu9LoNHMglAWqKm2b2PASjP8+lVZFhAEJ8WdFV/xIqG3MXRN+sfPdEYK4pfX qRFLnFb3cJZD96ope9gwrVrFwhDMIyimrDQR3doVhtL66Hzy8c5j6hsllXHsIsdr3w4F 1/++r4N7JlcWqMuQ9lmKkFuIj7RYup40kO5Lm8jnqGkm8hQL4upY9/JeDBq40R0mTsFa OYJ X-Gm-Message-State: AOUpUlENzsjhtDfG0D14e1rICdQl/OrGkBYdQz+yhshX+3T6I5aQcSN9 pJYNaTkHqT85n128LLXSSoqf6A== X-Google-Smtp-Source: AA+uWPyznR1oe3eCFOk+am7CdN3jxjm9qfqWcJyJbZ5gnycHZ1LEVmmQeQAEMZE+/DKdJJ3ojWAc+w== X-Received: by 2002:ac8:65c7:: with SMTP id t7-v6mr18147020qto.12.1534452108672; Thu, 16 Aug 2018 13:41:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a37:4c4c:: with SMTP id z73-v6ls3056951qka.6.gmail; Thu, 16 Aug 2018 13:41:47 -0700 (PDT) X-Received: by 2002:a37:7445:: with SMTP id p66-v6mr28731472qkc.368.1534452107495; Thu, 16 Aug 2018 13:41:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534452107; cv=none; d=google.com; s=arc-20160816; b=iJnX29uuIIwZ2ycWX0zx9R/GF5ScYhzZr3ZAJxLTEXOH1b9LKInxJcQfPGY+ErbAuc yMUf8ZEPRy9gqdRS+JdkzGuxDSPkl7NxaOs7WLEcr61qh929Kb/KEEbo9vSggRMUq7Pb EJwiDtirbdrA+ADxaKfwQx/694WYb/MluCLSDn3smszTxyh5ECSN0zzApoFh16U6zucA HR26YcbNO+4QGQEFS1U/wZa5CBXCyPUbGbBPTPNKh2b+sjZoMprv+MsKeN5KSFN5uueK bVJY6rR3BjrKRDiXxOBjkKmx/nRJ1qN2MlTBNz4Ustg63xkU1LxckzZdkP/g44ul0T9i D97A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:references:subject:date:content-transfer-encoding :mime-version:to:from:message-id:dkim-signature:dkim-signature :arc-authentication-results; bh=a8x96sJ1Wo37MkHutcPPiYO54w7JSfKa2SkdaqpqbVw=; b=KIdaqX9lw6BesBFUtXvVLFAXEMD0c7Ck7dRcPxSlZyOvi4vYO/JXXk6wYbYPHicrLL NPddUCosDQu1eyOlmcJbm4ZQ1ewkbXfJwJy7SBOFa29qO1rFSWe26FfOzRlpf26u2YnA Y4LY67fYjL0pHglBNabMquHXjLHWP8n1UVCZ97QNF3mTdSb1RqPChg8LP2vPcKQB88ks ftl+X9yUIQpvOWA9w4ilsF7CSJW0QnbG/hNrrYiGSolxAzWe7F98phZJeJSAX0WO+g5r tpGFM+c/PY/xUyfTwO+3s96lAHr9iReubAwbTCA0kypDQzjZX2XvlUfggHfvNEzLqNDX qFxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=sRh74+0c; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PWwpiCNT; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.com Original-Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com. [66.111.4.25]) by mx.google.com with ESMTPS id 199-v6si288150qkn.10.2018.08.16.13.41.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Aug 2018 13:41:47 -0700 (PDT) Received-SPF: pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) client-ip=66.111.4.25; Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BED7021F8A for ; Thu, 16 Aug 2018 16:41:46 -0400 (EDT) Original-Received: from web2 ([10.202.2.212]) by compute4.internal (MEProxy); Thu, 16 Aug 2018 16:41:46 -0400 X-ME-Proxy: X-ME-Sender: Original-Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0D16F621BF; Thu, 16 Aug 2018 16:41:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a In-Reply-To: <12ca0430-f790-4dee-b491-266435bae170@isocpp.org> X-Original-Sender: hank@millerfarm.com X-Original-Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@millerfarm.com header.s=mesmtp header.b=sRh74+0c; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PWwpiCNT; spf=pass (google.com: domain of hank@millerfarm.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=hank@millerfarm.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:39839 Archived-At: This is a multi-part message in MIME format. --_----------=_153445210537677200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thu, Aug 16, 2018, at 2:02 PM, Nicol Bolas wrote: > On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:>>= =20 >> In the past couple months I've seen several proposals for names >> parameters. Each with a list of pros and cons, and because there are >> cons arguments against them. I think we need a discussion on what we >> want assuming some strawman acceptable syntax, and some thought of >> how many limitations in corner cases we are willing to accept.>>=20 >> I can think of 4 uses for names parameters. (If you don't understand >> these I have simple code examples)>> 1 . a function with more than one p= arameter of the same type is >> called with the parameters in the wrong order>> * Some people= want this to be a compilation error, some want >> the compiler to correct the problem and continue>> 2. a functio= n wants to take the same type to mean different things in >> different contexts>> 3. it isn't obvious from the type alone what a p= arameter means=20 >> 4. A function has a bunch of defaulted arguments and you want to >> change one of the latter ones without specifying all the others>>=20 >> First question: is this complete?=20 >> Second, which problems are worth solving?=20 >> Third, for problems worth solving, which is the better solution, and >> how strongly attached to it are you?>=20 > 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. That comes next. First I want to brainstorm in a world where we are not constrained by possible to say what we want. After that we look at the other solutions, decide which are useful, and if any are good enough. Note in particular P0707 - metaclasses has using...as notation which make strong types easier to declare and might give everyone what they wanted. >=20 >> For the first the motivating code is something like:=20 >>=20 >> class myMatrix {=20 >> T GetCell(int row, int column);=20 >> ...=20 >> };=20 >>=20 >> in code:=20 >> cell =3D matrix.GetCell(column, row);=20 >>=20 >> This will compile just fine in C++17, but the code is undoubtedly >> wrong. In C++2n do you want this to be a compiler error, or >> correct code?>=20 > Note that making this "not correct code" would require that the > mechanism *require* that the user provide named arguments. That is, > you cannot use positional arguments at all. Right, the question is WHAT mechanism? When I write that I thought of 4 different ways to change C++ to accomplish this, and as it happens taging wasn't one. My 4 plus taging isn't a complete list either, it isn't even close. The point isn't to discuss how we want to do this, it is to discuss to we want to do it at all, and if so is it a compiler error or does the compiler just do what the user wanted. >=20 > Tagged dispatch can handle such cases. >=20 >> Second:=20 >> class point {=20 >> point(double x, double y);=20 >> point(double distance, double angle);=20 >> ...=20 >> };=20 >>=20 >> This code does not compile in C++17. Do we want to make this >> case work?>=20 > Tagged dispatch can work here. So can a properly named struct: > `point(Polar(dist, angle))`. Plus, by giving the type a full name, we > allow `Polar` coordinates to be passed around and used for other > purposes.>=20 >> Third:=20 >> class myString {=20 >> int compare(myString, bool CaseSensitive);=20 >> ...=20 >> };=20 >>=20 >> in code=20 >> if(str.compare(otherString, false) =3D=3D 0) ... // what does this >> mean, why would you call compare and not compare?>>=20 >> This code is legal C++17, but it is user hostile. False in the >> context of reading the function makes no intuitive sense. Qt has >> created an enum for this, but it can be argued that this is too >> heavy. (you may or may not agree with the argument)>=20 > The alternatives should be considered and discussed. Enumerators and > tagged dispatch both are good solutions. The argument against both is they are "ugly" This is of course subjective, but sometimes that is compelling anyway. >> Fourth:=20 >> // warning, marketing regularly changes the default value of this >> function>> void foo(double a =3D 1234.5, int b =3D 6789);=20 >>=20 >> foo(b:=3D1234);=20 >>=20 >> This won't compile in C++17. However it seems like it would be useful >> to not clutter function calls with default parameters that you don't >> care about. In the case I gave it is a maintenance problem to update >> all uses of foo every time the defaults change, though I'm not sure >> if this is actually a common problem.>=20 > There are several alternative solutions. A named struct works well > enough, thanks to designated initializers. Plus, it puts the default > values in a more accessible location, rather than the signature of a > function. It's not like users can get changes to such default values > without recompiling anyway.>=20 > 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`. Lots of options are possible. Do we like them? =20 I considered proposing a syntax llke 'foo(:=3Ddefault, 1234)' for this.=C2= =A0 I decided it wasn't worth it yet, but if we are not happy with the options adding something like this is possible. --=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/1534452105.3767720.1476682240.226BF14C%40webmail= ..messagingengine.com. --_----------=_153445210537677200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
On Thu, Aug 16, 2018, at 2:02 PM, N= icol Bolas wrote:
On Thursday, August 16, 2018 at 1:45:01 PM UTC-4, Henry Miller wrote:
=

In the past couple months I've seen sever= al proposals for names parameters.  Each with a list of pros and cons,= and because there are cons arguments against them.  I think we need a= discussion on what we want assuming some strawman acceptable syntax, and s= ome thought of how many limitations in corner cases we are willing to accep= t.

I can think of 4 uses for names parameter= s. (If you don't understand these I have simple code examples)
1 . a function with more than one paramet= er of the same type is called with the parameters in the wrong order
      *  Some people = want this to be a compilation error, some want the compiler to correct the = problem and continue
2. a function wants to take the same type= to mean different things in different contexts
3. it isn't obvious from the type alone w= hat a parameter means
4. A function has a bunch of defaulted ar= guments and you want to change one of the latter ones without specifying al= l the others

First question: is this complete?
Second, which problems are worth solving?=
Third, for problems worth solving, which = is the better solution, and how strongly attached to it are you?

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 so= lves 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 parameter= s.

That comes next. First I want to brainsto= rm in a world where we are not constrained by possible to say what we want.=

After that we look at the other solutions= , decide which are useful, and if any are good enough.  Note in partic= ular P0707 - metaclasses has using...as notation which make strong types ea= sier to declare and might give everyone what they wanted.


For the first the motivating code is somethi= ng like:

class myMatrix {
     T GetCell(int row, in= t column);
     ...
};

in code:
   cell =3D matrix.GetCell(colu= mn, row);

This will compile just fine in C++17, but= the code is undoubtedly wrong.  In C++2n do you want this to be a com= piler error, or correct code?

Note that making this "not correct code" would require that the mechan= ism require that the user provide named arguments. That is, you cann= ot use positional arguments at all.

Right, the question is WHAT mechanism?&nb= sp; When I write that I thought of 4 different ways to change C++ to accomp= lish this, and as it happens taging wasn't one.  My 4 plus taging isn'= t a complete list either, it isn't even close.

The point isn't to discuss how we want to= do this, it is to discuss to we want to do it at all, and if so is it a co= mpiler error or does the compiler just do what the user wanted.


Tagged dispatch can handle such cases.

Second:
class point {
    point(double x, double y); =
    point(double distance, doub= le angle);
...
};

This code does not compile in C++17. &nbs= p;Do we want to make this case work?

Tagged dispatch can work here. So can a properly named struct: `point(= Polar(dist, angle))`. Plus, by giving the type a full name, we allow `Polar= ` coordinates to be passed around and used for other purposes.

Third:
class myString {
    int compare(myString, bool = CaseSensitive);
...
};

in code
    if(str.compare(otherString,= false) =3D=3D 0) ...   // what does this mean, why would you call com= pare and not compare?

This code is legal C++17, but it is user = hostile. False in the context of reading the function makes no intuitive se= nse.  Qt has created an enum for this, but it can be argued that this = is too heavy.  (you may or may not agree with the argument)

The alternatives should be considered and discussed. Enumerators and t= agged dispatch both are good solutions.

The argument against both is they are "ug= ly"  This is of course subjective, but sometimes that is compelling an= yway.

F= ourth:
// warning, marketing regularly changes t= he default value of this function
void foo(double a =3D 1234.5, int b =3D 6= 789);

foo(b:=3D1234);

This won't compile in C++17. However it s= eems like it would be useful to not clutter function calls with default par= ameters that you don't care about. In the case I gave it is a maintenance p= roblem to update all uses of foo every time the defaults change, though I'm= not sure if this is actually a common problem.

There are several alternative solutions. A named struct works well eno= ugh, thanks to designated initializers. Plus, it puts the default values in= a more accessible location, rather than the signature of a function. It's = not like users can get changes to such default values without recompiling a= nyway.

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

Lots of options are possible.  Do we= like them?  

I considered proposing a syntax llke 'foo= (:=3Ddefault, 1234)' for this.  I decided it wasn't worth it yet, but = if we are not happy with the options adding something like this is possible= ..

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1534452105.376772= 0.1476682240.226BF14C%40webmail.messagingengine.com.
--_----------=_153445210537677200-- .