220 39829 <77719fdf-0f81-4c24-ad56-91826ef73032@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named Parameters for C++ Date: Thu, 16 Aug 2018 10:10:44 -0700 (PDT) Lines: 182 Approved: news@gmane.org Message-ID: <77719fdf-0f81-4c24-ad56-91826ef73032@isocpp.org> References: <5B758FFB.40507@westcontrol.com> <4f2cea6a-f66e-0305-41da-50f2d2ebf69c@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_467_227900228.1534439444304" X-Trace: blaine.gmane.org 1534439369 1336 195.159.176.226 (16 Aug 2018 17:09:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 17:09:29 +0000 (UTC) Cc: david@westcontrol.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBFPA23NQKGQEPWOWPEY@isocpp.org Thu Aug 16 19:09:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqLm0-0000F4-Lb for gclcip-std-proposals@m.gmane.org; Thu, 16 Aug 2018 19:09:24 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id d20-v6sf4632928ywa.16 for ; Thu, 16 Aug 2018 10:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=dhbXv3Xk+GufyU4MMxDHxZn7rkWv0YmmLRiLuzu/s5A=; b=KaiUJBcK5nw6oQN9KOEc7+r7Ghk7zvtESA6ojaffGIkF/1L4H6AeAferGnxomRmCGL farvrGFJfvGjWueqjKfM3ZgIz1DwcnfCOfWrc7yGiIRyAs2OLzNnGPz0VjLx0vKieb9+ +IfrJ0oUOe4OZEApK+ODS5+gqkev/94Ih3HXNig0Ju/gYv1WaKgl/QIhOIddhzvcqgpD 2XQuOduSXdwxNr3q4EjHQ2mE8aZmhWsBbt0L94VohfH0A50VhEgNUAg21bKo9gloSYW1 l+kgo+hezKw9+lHLD5dIdMyFE/OuLvV1APhjxHKszMfxRk5VEjFTJe/KLJRRqIfU8oRf hREQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=dhbXv3Xk+GufyU4MMxDHxZn7rkWv0YmmLRiLuzu/s5A=; b=CPy/MH4BStZQytVBwHMl6Hxs9cEBZ/1FGu+nnxJPLKPogGid5Lm9EYYnkVNkeb4gO2 9E7csq1xnHv64UQN7qYoqDNVo7uCuZ8oZVBO1g+beiywFWIfY/Wrg+GGA/hkfUlOP/3V p2r2uLdZN7C9rcQp12PTyc5YlMYIZMLokh3knCi81lFGFvgEEZUSOTYcWkdu0oHHyYZi zNruiAMZNSX/VojxGLuJ/rceX3MENCsahE5rtCsv5DeNLJv7HS/OTjDJLh+uM8GsBLgI mwgvQ5IYprHxeveGrm5pGhBTqDt3sSDfS8iIRThcGrtZzY+OG6/fv1xVfofqhfEQuEDt PRaQ== 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:cc: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=dhbXv3Xk+GufyU4MMxDHxZn7rkWv0YmmLRiLuzu/s5A=; b=aXb9wKKwRQb/V7CKFap8PDDhth2jn2zMDv4RrQclb7J26t2HfAZfBA5e6YmHVpBzsq /ndXGLWYWlsvZ0v2WpQBF3MkLEWnZSI5xXoXsutj+34IzdvBoYRPdqwoknFm5TIy2ETt T1Ja5x9IGjNfzWZAg/tflHarx955ewA0sS+6UxcFH7rZ8U6ZMistvfrrcmqlSgRYLe2C T638exKRUJL9VadicYy6ffMEIPm4MeBR0Wc3DESxYga7Cw/EKiHoVvLdy1kFGutdTjFz XkALHiDnZk2+88ihPsf99KexsH6AkKnyxgyCbnKoDSrCrCFui2y6unKYO+oZc/HasN0s QzRw== X-Gm-Message-State: AOUpUlHS2IUhJMSNAmSFN2tJBykvAiJDvmFdnFeYKS0tkbxFi9mzOkYv PQ4uHuupSw7G1PpdeUGea7mc3A== X-Google-Smtp-Source: AA+uWPwi8ACx+j2bLW7z0sFhvXdaHVOF5ztOqivh7nyntFhcdnX5uXGNLUeyPRojYMOZY6I3Jg47Kw== X-Received: by 2002:a0d:c8c5:: with SMTP id k188-v6mr8894105ywd.130.1534439494979; Thu, 16 Aug 2018 10:11:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:c101:: with SMTP id c1-v6ls622459ywd.18.gmail; Thu, 16 Aug 2018 10:10:44 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr611950ywc.7.1534439444834; Thu, 16 Aug 2018 10:10:44 -0700 (PDT) In-Reply-To: <4f2cea6a-f66e-0305-41da-50f2d2ebf69c@gmail.com> 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:39829 Archived-At: ------=_Part_467_227900228.1534439444304 Content-Type: multipart/alternative; boundary="----=_Part_468_1830355490.1534439444305" ------=_Part_468_1830355490.1534439444305 Content-Type: text/plain; charset="UTF-8" On Thursday, August 16, 2018 at 7:25:22 PM UTC+3, Matthew Woehlke wrote: > > On 2018-08-16 10:53, David Brown wrote: > > On 16/08/18 16:34, Matthew Woehlke wrote: > >> Checking argument order is, IMHO, not only *not* "the > >> primary use", but *optional*. > > > > Checking argument order is absolutely the key point in terms of helping > > people write correct code by spotting errors at compile time. It is > > also key to making code clearer by documenting parameters better without > > ugly "/* parameter_name */" comments. > > > > Those would be two /huge/ benefits to today's language, and can be > > implemented easily and cheaply. > > While I don't disagree with that, exactly, I also don't see it as a > compelling benefit. For me, named arguments are *primarily* about fixing > the problem of needing extremely flexible functions (read: large number > of parameters and/or large number of overloads) of which any *one* user > is only going to care about a small slice of the total surface area. I > only care about argument order to the extent it is useful in solving > that problem. Thus, for me, *the* killer features are being able to > specify one parameter in the middle of a list of defaulted parameters, > and/or to overload on parameter names. > Why overloading is so important to you? Because the first request is doable (default-by-mention or full rearrange), but the last is a *nightmare* to define *and* is doable today via workarounds. Can you please define names change the signature? Is this some sort of name-type pair? Is it a tag? Is this pure compiler help or part of the type system? And again, why is a killer? > > If I don't get those, I'd rather not muddy the feature space with > anything else. > > > Yes, you are right - you need the names to be part of the signature for > > name-based overloading. That is a key reason why name-based overloading > > should not be part of a first step for named parameters - it avoids this > > massive change. > > [...] > > [Forwarding] is very simple - as long as you drop name-based > overloading. > > [...] > > I think it is important to consider how they might be added later, and > > what effect that would have - and if possible leave the door open for > > name-based overloads in future versions. > > Right, so... here's an experiment. Explain how we could *later* add > name-based overloading on top of your proposal. > > If you can't do that, then accepting your proposal means we can *never* > have name-based overloading. Which means everyone that wants that is > going to be opposed to your proposal. > > If you *can* do that, I think it would make your proposal much more > compelling. > > -- > Matthew > -- 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/77719fdf-0f81-4c24-ad56-91826ef73032%40isocpp.org. ------=_Part_468_1830355490.1534439444305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, August 16, 2018 at 7:25:22 PM UTC+3, = Matthew Woehlke wrote:
On 2018-= 08-16 10:53, David Brown wrote:
> On 16/08/18 16:34, Matthew Woehlke wrote:
>> Checking argument order is, IMHO, not only *not* "the
>> primary use", but *optional*.
>=20
> Checking argument order is absolutely the key point in terms of he= lping
> people write correct code by spotting errors at compile time. =C2= =A0It is
> also key to making code clearer by documenting parameters better w= ithout
> ugly "/* parameter_name */" comments.
>=20
> Those would be two /huge/ benefits to today's language, and ca= n be
> implemented easily and cheaply.

While I don't disagree with that, exactly, I also don't see it = as a
compelling benefit. For me, named arguments are *primarily* about fixin= g
the problem of needing extremely flexible functions (read: large number
of parameters and/or large number of overloads) of which any *one* user
is only going to care about a small slice of the total surface area. I
only care about argument order to the extent it is useful in solving
that problem. Thus, for me, *the* killer features are being able to
specify one parameter in the middle of a list of defaulted parameters,
and/or to overload on parameter names.

Why overloading is so important to you= ? Because the first request is doable (default-by-mention or full rearrange= ), but the last is a nightmare to define and is doable today = via workarounds.=C2=A0

Can you please define names= change the signature? Is this some sort of name-type pair? Is it a tag? Is= this pure compiler help or part of the type system?=C2=A0

And again, why is a killer?
=C2=A0

If I don't get those, I'd rather not muddy the feature space wi= th
anything else.

> Yes, you are right - you need the names to be part of the signatur= e for
> name-based overloading. =C2=A0That is a key reason why name-based = overloading
> should not be part of a first step for named parameters - it avoid= s this
> massive change.
> [...]
> [Forwarding] is very simple - as long as you drop name-based overl= oading.
> [...]
> I think it is important to consider how they might be added later,= and
> what effect that would have - and if possible leave the door open = for
> name-based overloads in future versions.

Right, so... here's an experiment. Explain how we could *later* add
name-based overloading on top of your proposal.

If you can't do that, then accepting your proposal means we can *ne= ver*
have name-based overloading. Which means everyone that wants that is
going to be opposed to your proposal.

If you *can* do that, I think it would make your proposal much more
compelling.

--=20
Matthew

--
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/77719fdf-0f81-4c24-ad56-91826ef73032= %40isocpp.org.
------=_Part_468_1830355490.1534439444305-- ------=_Part_467_227900228.1534439444304-- .