220 40019 <5940029a-6a96-47d7-86cf-4ae915a1f86f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: What do we want from named paramaters Date: Sun, 26 Aug 2018 02:48:34 -0700 (PDT) Lines: 253 Approved: news@gmane.org Message-ID: <5940029a-6a96-47d7-86cf-4ae915a1f86f@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_629_1145315042.1535276914548" X-Trace: blaine.gmane.org 1535276791 10324 195.159.176.226 (26 Aug 2018 09:46:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2018 09:46:31 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB47ORHOAKGQEOGFQT4Y@isocpp.org Sun Aug 26 11:46:27 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftrcp-0002aV-6F for gclcip-std-proposals@m.gmane.org; Sun, 26 Aug 2018 11:46:27 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id 188-v6sf8167889ybv.9 for ; Sun, 26 Aug 2018 02:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=bvpEknlmLXNar9sFAyLeg7n13TGhRvGbU3clC/ZOk0A=; b=ZYLtO3S/sGK2XzQMIJMMbeBi3AHUZJI6RMOuwQAqpAJvNaRTO+LXuDitqSzvgbm6yh ufuPW5rEPxoF/GSXKpOsbxp7DcMrVCgOQSp7ZPK5/cF7QOgv3cVWALFyR+rNCD9T1uQX 0XWnpqKp6dV+NXD2rjwLOrwQWcq859lwJzwQP+2kgWAobk/HWQdG82J0xhHo/278qycX /KPHJ/jsWkOBoH8Y7Ln8kJ72AQq1ckKOHVQJUJGdiJ18p9lqyJb1l3cXbqqkg4FZXvLi xtt4qxeH/49+jgsb95WfenjDMFuWw+UfRxNwPT7bRfk1dklcXeviVUG1LixEjLGrC3uG y+eg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=bvpEknlmLXNar9sFAyLeg7n13TGhRvGbU3clC/ZOk0A=; b=RWL1E/zNI5sGAnTWe2IvHSp4pkb6OwFNyTRZGM71dNbR3cSzHEq6FPe5gdIoUhKwmv oq9VLprrlWfw94/wirTNryQMSTjuQuly40IC7N2FccUuBxDNegK2j2CVcVpS4SJ7dVL4 DVkyR2xZk5ax1CtCvkv/vbLS0hSSGC+dYkWWPeqrb54ea4kiDajtwmAawEAMPl991wfi pxAihD9KIrf21ZaSBb7d4B+TZk0Bo4JSkRXGVjf2o8ej9S+aTAzp/qY5R/N6zi94X0j9 uoIIrWEHJ0pe4d1CZ/1F5MCSrecS/6LxM+yKCZuB4IRkjFrrAlXD6218k8bPfN1npLz+ 0jEQ== 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: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=bvpEknlmLXNar9sFAyLeg7n13TGhRvGbU3clC/ZOk0A=; b=ucnHSDU8ss/rGuHk++z7Vd+78qQ+ZqmW7h3l9dsXSaHQBhgdK9UuC4rpaLhZcw4k3h EDfgziJzMUDG/1FOx8qJx+rfrH/WlApmOROGgaCcWs+A4Ynu9Ls+virbMLSeuWmOB3UH xedK9yngUFD3lI7qwu36grpV06QCs8lQ6PvW3CFbzV0DLtkxDYdWCIj8itnMKBHN3wRw in4JwxHcinEqDQXUcMopZMYXaQu4y1YIRXg9EUcCOX9UxXtw+USckTkKe4adUMZpwJGW PtYg0Z4OjveqZiwl41eNozjqr6WHrMRlZFfi1v7xnN+pv0nSOMvWM/ksFZGw8lFymxwv jDcg== X-Gm-Message-State: APzg51D7Bq2z4U+tMz/RMycRtmG7JV13KuXWUR6P3dkrly3evRAzeBa+ HgcYck7hdXwwMc92QVPQhlzHTw== X-Google-Smtp-Source: ANB0VdaDJvBAbPwJvuUDYKtDhKWtTaQLQ3NdHgHMkl7WAAFlPXtlgTHhMhYnU3mGIecxfJe5ghdd0A== X-Received: by 2002:a81:8742:: with SMTP id x63-v6mr3023456ywf.108.1535276916692; Sun, 26 Aug 2018 02:48:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:32d7:: with SMTP id y206-v6ls2818331yby.2.gmail; Sun, 26 Aug 2018 02:48:35 -0700 (PDT) X-Received: by 2002:a25:2483:: with SMTP id k125-v6mr107939ybk.5.1535276915131; Sun, 26 Aug 2018 02:48:35 -0700 (PDT) In-Reply-To: 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:40019 Archived-At: ------=_Part_629_1145315042.1535276914548 Content-Type: multipart/alternative; boundary="----=_Part_630_950672733.1535276914549" ------=_Part_630_950672733.1535276914549 Content-Type: text/plain; charset="UTF-8" On Sunday, August 26, 2018 at 7:24:06 AM UTC+3, Hyman Rosen wrote: > > On Fri, Aug 24, 2018, 6:00 PM > wrote: > >> On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hyman Rosen wrote: >>> >>> On Fri, Aug 24, 2018 at 4:22 PM wrote: >>> >>>> On Friday, August 24, 2018 at 10:22:11 PM UTC+3, Matthew Woehlke wrote: >>>>> >>>>> On 2018-08-24 15:03, mihailn...@gmail.com wrote: >>>>> > That aside, it seems so far the weak names are the only ones >>>>> desired. >>>>> Really? >>>>> Granted, I'm not sure at this point what "weak names" means, but I'm >>>>> not >>>>> sure I agree with that statement. >>>> >>>> As far as the votes so far are concerned. As you know, I believe we >>>> need both. >>>> >>> >>> >> >>> I don't see why leaving declarations alone affects using parameter names >>> to specify arguments. >>> >> >> Because the user code starts depending on things, the library author >> might not want it to depend on. >> Much like "don't reopen std", "don't take the address of a std function", >> library authors want the arguments to remain outside the interface to their >> code. >> > > 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. And it is not just "library authors" breaking "users" code. Think about a class that has a public interface and private implementation, be it private functions, functions in anonymous ns, pimpl etc. Ok, one will be a good guy and be careful to pick correct names upfront for the public interface, what about all *other* functions that a *coworker* might use? Dozens upon dozens helper and implementation functions across all sorts of files with different state of stability! 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! > >> From a practical standpoint, the author might want to introduce naming >> partially either because the code is in flux, >> or simply because he considers only few argument important and worthy of >> standardizing - after all it is his interface, he should be able to design >> it how he wants it. >> > > No. It's much more important to have a consistent language. Letting > people decide that only certain parameters are named is silly. > 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. 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? This tiny example shows all the problems with reusing arguments for names - arguments *might* or might *not* require design and expressiveness, names, *always* *do*. 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! * And so on, reusing arguments creates problems *bigger*, then the "simplicity" it promises: 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) There is a reason this idea did not get traction in 91, no need to go the same path again. We should move forward. > > Also, with a separate syntax the author *should* be able to use any word, >> including keywords >> > > This is ridiculously unnecessary. > -- 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/5940029a-6a96-47d7-86cf-4ae915a1f86f%40isocpp.org. ------=_Part_630_950672733.1535276914549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, August 26, 2018 at 7:24:06 AM UTC+3, Hy= man Rosen wrote:
On Fri, Aug 24, 2018, = 6:00 PM <mihailn...@gmail.com> wrote:
On Saturday, August 25, 2018 at 12:16:12 AM UTC+3, Hy= man Rosen wrote:
On Fri, Aug 24, 2018 at 4:22 PM &= lt;mihailn...@gmail.com> wrote:
=
On Friday, August 24, 2018 = at 10:22:11 PM UTC+3, Matthew Woehlke wrote:
On 2018-08-24 15:03, mihailn...@gma= il.com wrote:
> That aside, it seems so far the weak names are the only ones desir= ed.
Really?
Granted, I'm not sure at this point what "weak names" mea= ns, but I'm not
sure I agree with that statement.=C2=A0
As far as the = votes so far are concerned. As you know, I believe we need both.

=C2=A0
I don't see why leaving declarations alone affects using para= meter names to specify arguments.=C2=A0
= =C2=A0
Because the user code starts depending on things, the libr= ary author might not want it to depend on.=C2=A0
Much like "= don't reopen std", "don't take the address of a std funct= ion", library authors want the arguments to remain outside the interfa= ce to their code.
Too bad?=C2=A0 If we have named parameters, parame= ters will have to have meaningful names.=C2=A0 That's a good thing anyw= ay, because it helps document what functions do.

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

And it is not just "l= ibrary authors" breaking "users" code.=C2=A0

<= /div>
Think about a class that has a public interface and private imple= mentation, be it private functions, functions in anonymous ns, pimpl etc.

Ok, one will be a good guy and be careful to pick c= orrect names upfront for the public interface, what about all other = functions that a coworker might use?=C2=A0
Dozens upon doz= ens helper and implementation functions across all sorts of files with diff= erent state of stability!=C2=A0

Without an ability= to pin a name as stable there is no guarantee ever one is no= t breaking someone else's code, even his own.

= What would be the solution to this? A convection? Documentation? How is thi= s better then expressing it all in the code itself!
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

From a practical standpoint, the author might want= to introduce naming partially either because the code is in flux,
=C2=A0or simply because he considers only few argument important and wort= hy of standardizing - after all it is his interface, he should be able to d= esign it how he wants it.

No.=C2=A0 It's much more important to = have a consistent language.=C2=A0 Letting people decide that only certain p= arameters are named is silly.

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

How to name the argume= nt of=C2=A0sqrt? Why is it name= d that way? Is it self-explanatory? Do you know how it is called according = to the standard library right now? Which implementation of it?
This tiny example shows all the problems with reusing argument= s for names - arguments might or might not require design and= expressiveness,=C2=A0 names, always do.

=
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 a= nd documented in cppreference? But this is wrong, end is not last, but o= ne past last!=C2=A0

And so on, reusing argumen= ts creates problems bigger, then the "simplicity" it promi= ses:

=C2=A0Every 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&quo= t; like in swift sqrt(_ val: double)

= There is a reason this idea did not get tra= ction in 91, no need to go the same path again. We should move forward.
=C2=A0

Also, with= a separate syntax the author should be able to use any word, includ= ing keywords

This is ridiculously unnecessar= y.

--
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/5940029a-6a96-47d7-86cf-4ae915a1f86f= %40isocpp.org.
------=_Part_630_950672733.1535276914549-- ------=_Part_629_1145315042.1535276914548-- .