220 40034 article Path: news.gmane.org!.POSTED!not-for-mail From: Hyman Rosen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Mon, 27 Aug 2018 11:01:15 -0400 Lines: 181 Approved: news@gmane.org Message-ID: References: <1534441498.3721109.1476442920.71D445BF@webmail.messagingengine.com> <73b10960-8c70-419a-b317-2d78ec46a1d7@isocpp.org> <8e2b5a47-f22b-4cd6-ba68-9802bfff7bc1@isocpp.org> <9b26b74c-41c6-46c1-974e-1cd39f036a96@isocpp.org> <5940029a-6a96-47d7-86cf-4ae915a1f86f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e5a46a05746bfff3" X-Trace: blaine.gmane.org 1535381964 14662 195.159.176.226 (27 Aug 2018 14:59:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 14:59:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKJJPVBQMKRBSNESDOAKGQEPRJSAOQ@isocpp.org Mon Aug 27 16:59:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fuIzA-0003go-FC for gclcip-std-proposals@m.gmane.org; Mon, 27 Aug 2018 16:59:20 +0200 Original-Received: by mail-wm0-f70.google.com with SMTP id 199-v6sf7707302wme.1 for ; Mon, 27 Aug 2018 08:01:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1535382090; cv=pass; d=google.com; s=arc-20160816; b=crRE+bc+XFgU02njOE/zHmt0M8dLGIg6mkBVC7nWS7227iB7H9n9iNwGW2LDHEfx7A SXsAkjKPdxqLczlDNNc9/wAe6oppqm3hM5ykhjRJDoKxHJBXJuVJvnAPxoHhn6ZeLC6w K+ElYyg3CjofU6ezoXBk+GJjE+LFlXUEX3VKwMAUrqTS6JxlYIvbNcHjjKmb4rKwU0t4 8jMXGFoJkUvwkW2eu563Rl3miREX50wZRRZQwbf74RMLPRV/wFni05uYJedU6zXc0aL/ 10DiCSqAKODlEc1QIHi3udEWxcfiIS3dvEzLFNT4baKYtTQTXNLYGJ3yvSZ5HuGSmm28 v0xg== 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=VZS2ySKeRDdeL8WEHIRNEUdrt2h/kr5+C3S8c75u2dU=; b=GJp4+RaWTL228wsYklVCZ3lc2WoOdi+X9nyA8bcy5UBEataTqqLsyui+I4C1zVs818 zQgzftq30e3bpOrtw+4G7DVINh8zB7D7hR53KfoSOeBKmuusmFeUrHR9038mOEADlv8L 4+PmaEbu8S+X205Q0OFUK9tSa3KNsd3UBpQvLxKqLHP/Zobu3qtGm5z7BH1JE65e12Ec iK6SDV3JGu4WU0+I7TSyS516JGcXl5iYXTRPbX3aEh7En67naI4DKUDanxyV2ksu2sRF JiyYENBPNYZZDFKzC61EX4NrsmXNqrzqXw+OYp1x1OmLXp6T+yAiiT/1tLCToApARA4x bQwQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=THfAAAPF; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@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=VZS2ySKeRDdeL8WEHIRNEUdrt2h/kr5+C3S8c75u2dU=; b=BdT0QoaXvVhTNdXs9sUMAhILhEX1kYoJPlsIt6X6G2k9dPWBtVhCHe41HtbzVo0WWS Og4OpcWeXyOdB9WG9w/Accek4U8WNssraz9dgX0Z4u3uRy2+Up7z/H4t79ekJO+KonBK u4hIacb0tGmq2yWYja6DkIcYVMXS1xg9G1vmVxkJzVLFdt8wWVBECz/q0AwAu9R/Q0JY j5Ms8S6jAvB4sggrAKIfwpk3d/BpbB9gb23kWfBSQku/WKbas1CdNnUtHxMjgfQDR5YR StIik7oIPV83MAjIT55I0k63hVE8cssh/lGJzqDBIUnRvEhjVIz3nLMszcujPzNbz/PS u6VA== 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=VZS2ySKeRDdeL8WEHIRNEUdrt2h/kr5+C3S8c75u2dU=; b=Fh0v5/f7ZEjr/jmvcFIdpBWfJWsNQaxd8PWa7/aoJSMwI37SqY1RL1UrYYTqmQs0sc bCcxrTT7ikv3ZEtvwzk7WtytGczJEUyrzH+VICzJwCY3WkYZYdKLaR9mN7sFcDe8unxn FaPvpq4pX08C2zxvuvPGXhFu5mnI+ew8hVTFU6XvDDdf47G6R7es6FRDVCnzsd1Yr5V8 nai55t5QtfSttN37aEtlovHwjJ7hm3DAQc0p6G/oEYsy1266A/nEroYU78jRdtj7sV9j eDrZlWhkIxKVCungerxHIkQd7RdbtZNAqTLy43PXlUjjWCbPqApeykss/zK4AZeiYu+t p84g== X-Gm-Message-State: APzg51A0Z/0ZBByBRHilRsBsyUmA2D6RHzIYUHap/ubyzNG8U6nVfhHA f62nB5ZyBxT7qrnkcovHdJzIxg== X-Google-Smtp-Source: ANB0VdYYWWCnI4v/2HgWCOq66GeCT0ScHnE40qMbunpPCF6SiOdHJjS01OY5g7/hxKKl0z8eR+5fAw== X-Received: by 2002:a1c:85d2:: with SMTP id h201-v6mr983530wmd.9.1535382090604; Mon, 27 Aug 2018 08:01:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:f2ce:: with SMTP id d14-v6ls3800017wrp.14.gmail; Mon, 27 Aug 2018 08:01:28 -0700 (PDT) X-Received: by 2002:adf:ee86:: with SMTP id b6-v6mr8708010wro.242.1535382088464; Mon, 27 Aug 2018 08:01:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535382088; cv=none; d=google.com; s=arc-20160816; b=rMcVs04HzoFwSzZhdmdF559cALITvoB/uHMSP3mviRAN0xckTlP6vUZmrnWqXynxYo b0dEYrEqRG0ubSFR+XKEkcDqk6PayI0wKp0FoPxQRd8oG6hyWneJvc+jKqmHcHvvZPHr EmBPe6Z6p34WePBnAgc6rT5bqcSDwlI7ImRbER7wfLs7nrVApbRlhrb7Ly8llk5e3b5O LogCcPSwpqMDKvrUk2pEv65nu715n8LkKSAfd7i3JmL3V1KYthSaOhyxmbI0Wq0VQ74e sgPh0wjT97VCFHLumH0H2pWwUPiB7NvJh0PVRqZWSHX5M/livDHGDOjPnT43Anpr22Mb aVfg== 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=lqzqMhlejTTcGhge1LkKHGuXpkUAveJO9ieSJtSYdGg=; b=D9MkeyBzzH7aR86bYjuruw/HdZg2LL4PaFH2gB0y3T5tjmYonHPqtWnMS5ZU34ZnW5 0ZR+606sU9oTLAyNChd2EJcwVGWJaeOmHbant9fGUTLrAetdg4dUd4GiXdWs3N53kq+k WW2i4w5+0JQDG/voY7lTsB755PA1aGsje1umA4gjstAxkojuJ02TvZK4BwrPgmeoHv5Y UxyHknX24KadXvPZgLZixz8B6G+Az0EOWz52qg7CTgB9/vm3OgCpaoml04rbNP7UAH3p 5LimE2raBSml8kUHPK/kZxHKBz6zb6U6hYaLF5R4jVhJ5AhsX2RbfonGhQLDqbMH4l6j 1NRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=THfAAAPF; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@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 i9-v6sor5236485wre.80.2018.08.27.08.01.28 for (Google Transport Security); Mon, 27 Aug 2018 08:01:28 -0700 (PDT) Received-SPF: pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:adf:eb87:: with SMTP id t7-v6mr8827608wrn.123.1535382087114; Mon, 27 Aug 2018 08:01:27 -0700 (PDT) In-Reply-To: <5940029a-6a96-47d7-86cf-4ae915a1f86f@isocpp.org> X-Original-Sender: hyman.rosen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=THfAAAPF; spf=pass (google.com: domain of hyman.rosen@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hyman.rosen@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:40034 Archived-At: --000000000000e5a46a05746bfff3 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 26, 2018 at 5:48 AM wrote: > Too bad? If we have named parameters, parameters will have to have >> meaningful names. That's a good thing anyway, because it helps document >> what functions do. >> > > Sure, in principal, but in practice this is not always possible or even > desirable, especially considering the prize to pay is breaking someone's > build. > The parameter names become part of the interface. If you change method names, you can break a build. If you add overloads, you can break a build. If you change parameter names, you can break a build. So don't? Or notify the users first? Other languages with named parameters seem to have coped. Without an ability to *pin* a name as *stable* there is no guarantee ever > one is not breaking someone else's code, even his own. > What would be the solution to this? A convection? Documentation? How is > this better then expressing it all in the code itself! > The "explanation" is the name of the parameter in the declaration. Nothing more is needed. It is not so silly, even if we take stability of the code away from the > picture (and we can't, but lets say we do) - often the name is redundant > and/or there is no good name. > The parameter must have some name. That becomes the name used for named parameter passing. How to name the argument of sqrt? Why is it named that way? Is it > self-explanatory? Do you know how it is called according to the standard > library right now? Which implementation of it? > It's named 'x' because that's how the C standard refers to it. The parameters of operator<= are named 'lhs' and 'rhs'. Whatever. Some name gets picked, and that's the name. This tiny example shows all the problems with reusing arguments for names - > arguments *might* or might *not* require design and expressiveness, > names, *always* *do*. > Parameters always require expressiveness, because the contract that defines what the function does needs to refer to them in a way that makes sense. (Which, by the way, can be the next fight - national language arguments over named parameters.) And it does not stop there. Do you really need the begin and end iterators > of every algorithm named? And how would you name them? begin and end, > possibly colliding with the functions? > first and last, like they are now *unofficially* called and documented in > cppreference? *But this is wrong, end is not last, but one past last! * > Yes, we need them named, because the contract that describes what the function does has to refer to them by name. If 'begin' and 'end' are the best names, then those are the names to use, and the implementation just has to deal with it. Every argument ever, on every function ever,* can break code*, AND every > argument is essentially *mandatory* to design, you can't even mark it as > "name can be skipped" like in swift sqrt(_ val: double) > Huh? Named parameters don't eliminate positional parameters. If you want to call sqrt(7.3), that works fine. (I'm assuming the Ada version of named parameters, which is a leading set of positional arguments followed by a trailing set of named arguments in arbitrary order, with defaulted parameters elidable.) -- 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/CAHSYqdaF-UCWCkR0CbgeCU_y6Bg51Hwjy8_ft2Lfxc91n7B-CA%40mail.gmail.com. --000000000000e5a46a05746bfff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 26= , 2018 at 5:48 AM <mihailnaj= denov@gmail.com> wrote:
Too bad?=C2=A0 If we have named parameters, parameters will have = to have meaningful names.=C2=A0 That's a good thing anyway, because it = helps document what functions do.

Sure, in principal, but in practice this is not always possible or even = desirable, especially considering the prize to pay is breaking someone'= s build.

The parameter names become part o= f the interface. If you change method names, you can break a build.=C2=A0 I= f you add overloads, you can break a build.=C2=A0 If you change parameter n= ames, you can break a build.

So don't?=C2=A0 Or notify the users= first?=C2=A0 Other languages with named parameters seem to have coped.
=
Without an a= bility to pin a name as stable there is no guarantee ever one= is not breaking someone else's code, even his own.
What woul= d be the solution to this? A convection? Documentation? How is this better = then expressing it all in the code itself!
The "explanation" is the name of the parameter in the declaratio= n.=C2=A0 Nothing more is needed.

It is not so silly, even if we take stability of th= e code away from the picture (and we can't, but lets say we do) - often= the name is redundant and/or there is no good name.

The parameter must have some name.=C2=A0 That becomes the name u= sed for named parameter passing.

How to name the argument of=C2=A0sqrt? Why is it named that way? Is it self-explan= atory? Do you know how it is called according to the standard library right= now? Which implementation of it?

It's= named 'x' because that's how the C standard refers to it.=C2= =A0 The parameters of operator<=3D are named 'lhs' and 'rhs&= #39;.
Whatever.=C2=A0 Some name gets picked, and that's the name.
This tiny e= xample shows all the problems with reusing arguments for names - arguments = might or might not require design and expressiveness,=C2=A0 n= ames, always do.

Parameters = always require expressiveness, because the contract that defines what the f= unction does needs to refer to them in a way that makes sense.=C2=A0 (Which= , by the way, can be the next fight - national language arguments over name= d parameters.)

And it does not stop there. Do you really need the begin and en= d iterators of every algorithm named? And how would you name them? <= font face=3D"courier new,monospace">begin and end, possibly colliding with the functions?
first and last, like they are now unofficially called = and documented in cppreference? But this is wrong, end is not last, but = one past last!=C2=A0

Yes, we need them= named, because the contract that describes what the function does has to r= efer to them by name.
If 'begin' and 'end' are the best = names, then those are the names to use, and the implementation just has to = deal with it.

=
=C2=A0Every argument ever, on every function ever, can break code, AND every argument is essentially mandatory to design, you can&#= 39;t even mark it as "name can be skipped" like in swift sqrt(_ val: double)

Huh?=C2=A0 Named parameters don't eliminate positional pa= rameters.=C2=A0 If you want to call sqrt(7.3), that works fine.=C2=A0 (I= 9;m assuming the Ada version of named parameters, which is a leading set of= positional arguments followed by a trailing set of named arguments in arbi= trary order, with defaulted parameters elidable.)

--
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/CAHSYqdaF-UCWCkR0= CbgeCU_y6Bg51Hwjy8_ft2Lfxc91n7B-CA%40mail.gmail.com.
--000000000000e5a46a05746bfff3-- .