220 40088 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named Parameters for C++ Date: Wed, 29 Aug 2018 15:32:49 +0100 Lines: 170 Approved: news@gmane.org Message-ID: References: <5d064165-5a58-4810-90f7-aa3732be92db@isocpp.org> <60449422-b543-4949-557a-96435c1c2926@technion.ac.il> <3e50834d-2e56-392f-fe30-8c24769d7647@gmail.com> <44b180b7-9c2f-48fe-9cf5-5b803b45f460@isocpp.org> <0341abf7-070d-4dd6-88d3-b7072b991cd4@isocpp.org> <0fe2a8da-3442-edbe-7bdf-40d6b1c90d1b@gmail.com> <28f2a655-1a1b-4386-9f76-c16ddb1647e6@isocpp.org> <4f02dc49-5945-f245-c7ca-76d2d9ab83be@gmail.com> <8693c5c4-d544-1ee0-ae12-b3c2f5c1537f@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b84ab4057493d5b1" X-Trace: blaine.gmane.org 1535553054 17137 195.159.176.226 (29 Aug 2018 14:30:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2018 14:30:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBGW5TLOAKGQEK3FC5XQ@isocpp.org Wed Aug 29 16:30:50 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv1Ug-0004Mw-4p for gclcip-std-proposals@m.gmane.org; Wed, 29 Aug 2018 16:30:50 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id h20-v6sf4581777iob.20 for ; Wed, 29 Aug 2018 07:33:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1535553180; cv=pass; d=google.com; s=arc-20160816; b=zLAAfMZTIxVA+/LJYqadMW8c814vQWdyBUwpyXIJwQNEYmYhWBUkoAKyRe4y2QY2W4 6jDIaj9Han0p7mi/5s3rV+biUMU3rqipMlh1CZxW9VdvODSC1e9JlVfcvECQTs2XuF9s tFJJpv0KOhB1HXwSYxGkaCpWhMLKfLIvj/TN86IzCxUPQ9SQ2hMScpTzLyecVoDfKxXw nrMtsj6567aDmIGglBNSGL3qvcurMeP7L4JQJJag0REEBR08TuXEKwqarknkO6/DJVGf Pk5CiylMeIkpu31a7fBTKTAUnvo9jYQV+AWGHL5bcRljHavHkmeN5NfIpBcQe6ITB4Y1 WDXg== 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=zPoIl8VCKhIqS8XfjdKfBq6G9BHHGxCsNlvlhIQCqQI=; b=FAD84s6JNCyZCu+JVM90uY00L5MiwQmm0oDP6JQGL3iK/Iv3yTsRu7Dz27FPVgtu8c gpGk12LvjY3cVpVclEQtLrHQYkQcvai1vJDCF5AIf5TbCa3pVxZG34s75Z17d0efKpWL oslbJEUl4ehWj4mu3K2bW3qrr2BI7IxL8tyuY05jjLdJEhQXdBUg5X6Cww3YQeBHW/Lx DGgBAN1u6ouUHO6vA2T4eyU3bWY02oJjnIsF3jgQB6owH1Ln9WAatiegHCsUH1xo0I/a WqyyvCnt8umq2nOS55NQpEW7SGNlxA+gWPcGma7VoHcaTn2CylQEfz8hztT0W1zFJsJ5 jaNQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fQK32x5h; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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=zPoIl8VCKhIqS8XfjdKfBq6G9BHHGxCsNlvlhIQCqQI=; b=PmtqNZeHrEfO/vNpzk3t9KawrQU2SgloOQ/PvwI/46inf+LyiwJ0TfJMMY/qRojEKj kpth8/Fe1B71XYyFS58DDXo5LIIZz4CiRYExwwzajoKUMSv47Dvw/ZSNrLgEsFWUGBvk 0AnXUMap88QKUXjD0E3aEDBYmJl5ulJzokW1tmgebuyQxG0aTM55DJtLM1ZcV+LiWC7i xGXSBsNfxs3Fu5l04uTVPNAUsGXpxpmH/Ej7Yy4s/BzEss/Z/ADGPck4UmftPyDZxwHN d9RB5jiTM4rCDpHmvtO9cMB3Nuy1fzf2orPqCEjyUlh7Aryj+B1NiIQWBpqWCvMWNmQ5 TtWg== 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=zPoIl8VCKhIqS8XfjdKfBq6G9BHHGxCsNlvlhIQCqQI=; b=n8GHiAeoTJHl4Hmh71mjadq2AeP84oEachq6/Fll1BLx70D92zOpL+TKroQgrqySXV a7pPgIUyWzIfO4+iKr/onDQDv+UeTKgYX+G9fhvgrDxUclsRd94E4xGX0QVDvZX63q8T L0LpfYmOreU98jFahDAAyOcfog4v2xPy9ewMtGdbK9GQpIfbXpBgQL2hpqRWVpN363u/ rJ+sceuZjJkGmASiT1PdNgDauvoqZX9xJaiDKvGgfz22Uxz406x653p+1BtzgTHSgwuO 97lzDDbNDN2u7boTZHg0KJ6uDFT/j6CWBdKqvC3OuHROXTvduvU5laVHTDkBn7HPK9sc Gu5g== X-Gm-Message-State: APzg51Cgr31F3UPZ0249CAMBiZ27zsynWjOEEt7bk+kl9/PdbvQtzNeE agNKUB2b9/go/zLIdfkHfOnmVA== X-Google-Smtp-Source: ANB0VdYPkptUz7Uo7s7vkZSU6pSTSlbILk446ERj0PuIII5JC2xoSV5GYf+RLkY24Uohi9wbsNEH1g== X-Received: by 2002:a5e:db4d:: with SMTP id r13-v6mr2516377iop.121.1535553179900; Wed, 29 Aug 2018 07:32:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a6b:530d:: with SMTP id h13-v6ls777904iob.17.gmail; Wed, 29 Aug 2018 07:32:58 -0700 (PDT) X-Received: by 2002:a6b:a0d2:: with SMTP id j201-v6mr5072576ioe.41.1535553178689; Wed, 29 Aug 2018 07:32:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535553178; cv=none; d=google.com; s=arc-20160816; b=bogcy7MnOz2U/+OmQeBBAr7H6/QY1OphnIGCkbsDXmpfK6xucyuAYfnAiBkvyhR5Kt Hilqp7+1b67pzTs8RsodQk18FHIo8UR6ROV0joFzruwwupxD2wXVrnnTvEZwHcPdb3hO UQofJWRtrxG2DbXUFqUgFGIMKaSlVlBSsTsEWRMEJGXzwRqEUmNuDIoWLy3YnmwPhyOi lUcsrC8awO21wC+yJiGxnCg5oIWTDdm0A9e8IuDWjsxme6wlHbMP6shIM8mva/oiJ82q 1SOZ133DCC1YY+UxqScFPGau4xW1SbBmpfsmTABOu1ofW7SSEF75CYKo6KxTFQSOQvVZ j+aQ== 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=ET2rjAxv3FV/xpUux2uDWPAB0zFnvwq87EPq3n6ps7k=; b=BKFmeC7/lsAQZSDrmBj6qWtpTig0XgucgNvuErkGsoZpJWweEg1O1br7q/1lYHuIum /oLcnnj38iHVYNenPN2ov1LeYtBSgRWBRlQQBrqpF6gqSx6ynLK3XbEHtFQw3LV3rpy2 3iCHMoNqQg4hSNfXewsL2ausmbWw6Gie9FhPnNcJV4C6eTAcwVDQrbz00rDAUuxIpagz K+ErM0SSeReNghRJGU3PU0l2wqqmBo1bDwu/OklTMhWONau1GWFhME3gGVRE1Te4I96k 8UEu4FvpP/e4UtVaM0oMZtGT1f/57LMcPmumV+e6B+BrqNdwXSqZBACdKWk0hLakDlLY bAjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fQK32x5h; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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 p197-v6sor1706215itc.43.2018.08.29.07.32.58 for (Google Transport Security); Wed, 29 Aug 2018 07:32:58 -0700 (PDT) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a24:37d2:: with SMTP id r201-v6mr5343782itr.113.1535553178191; Wed, 29 Aug 2018 07:32:58 -0700 (PDT) In-Reply-To: X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fQK32x5h; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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:40088 Archived-At: --000000000000b84ab4057493d5b1 Content-Type: text/plain; charset="UTF-8" On Wed, 29 Aug 2018, 14:19 Hyman Rosen, wrote: > Again, I disagree. Optional parameters have default values that callers > can duplicate, so your first obiection is irrelevant - people can always > have done that. > It's possible to, but it then becomes a conscious effort, and the user has presumably read the documentation and may know of unwanted behaviour. It's possible and reasonable to assume that there exist functions which branch off of each successive parameter - not good design, but it works. It's reasonable because the existence of prior parameters is an established fact, and users knowingly entering an error value for a previous parameter do so intentionally. With named parameters, they may do so *unintentionally.* Sure, that's not a breaking change in the traditional sense. But changing the way parameters are injected will mean that a trusty old API can turn into a confusing mess. That's why I'd rather the control remain in the hands of the library writers - adding a new way of interacting with their code means they have something new to worry about inside unchanged code. In any other language that would be something I wouldn't care so much about. But C++ code in the wild has the tendency to move forward at the rate of treacle, and adding a new potential site for bugs concerns me. That's the reason I'd want this to be opt-in. As for the second, there will be plenty of time for library writers to > adapt. If the library is under maintenance, they'll change the parameter > names if they care. If it isn't, the names will be whatever they are. > Library writers hellbent on denying users the feature can leave out > parameter names in their declarations altogether. > That they can. But they still have to change it. We have never functioned based off of "there will be plenty of time for library writers to adapt" and I don't see why we should start now. > So if we need to provide a way of users doing this explicitly, the >> underlying implementation need not act as a function as we know it. If the >> curly braces are too much to demand, we only need to provide a way of >> implicitly converting a parameter list into a struct which can be >> constructed in a name-based manner. >> > > Since I don't think we need that, I think everything should stay the same > and leave named parameters purely as an internal compiler thing. > Though we still have to force them to work in a certain way because instruction ordering needs to be consistent. void f(int a, int b); int x = 0; f(.b = ++x, .a = ++x); Does 'a' get given the value 1 or 2? The approach used by compilers will need to do this consistently, and thus we are pinning them to an implementation. While we're doing that, being able to call f(.a=some_expensive_function(), .b=.a); Might be useful to someone out there. > -- 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/CAC%2B0CCPUyyJm5RTxkhd7EszyoQ56hpo9sv5JUnja5N3n8_WxaQ%40mail.gmail.com. --000000000000b84ab4057493d5b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, 29 Aug 2018, 14:19 Hyman Rosen, <hyman.rosen@gmail.com> wrote:
Again, I disagree.=C2=A0 Optional parameters have default values that= callers can duplicate, so your first obiection is irrelevant - people can = always have done that.

It's possible to, but it then bec= omes a conscious effort, and the user has presumably read the documentation= and may know of unwanted behaviour. It's possible and reasonable to as= sume that there exist functions which branch off of each successive paramet= er - not good design, but it works. It's reasonable because the existen= ce of prior parameters is an established fact, and users knowingly entering= an error value for a previous parameter do so intentionally. With named pa= rameters, they may do so unintentionally.
Sure, that's not a breaking change in the trad= itional sense. But changing the way parameters are injected will mean that = a trusty old API can turn into a confusing mess. That's why I'd rat= her the control remain in the hands of the library writers - adding a new w= ay of interacting with their code means they have something new to worry ab= out inside unchanged code.

In any other language that would be something I wouldn't care so muc= h about. But C++ code in the wild has the tendency to move forward at the r= ate of treacle, and adding a new potential site for bugs concerns me. That&= #39;s the reason I'd want this to be opt-in.
As f= or the second, there will be plenty of time for library writers to adapt.= =C2=A0 If the library is under maintenance, they'll change the paramete= r names if they care.=C2=A0 If it isn't, the names will be whatever the= y are.=C2=A0 Library writers hellbent on denying users the feature can leav= e out parameter names in their declarations altogether.

Th= at they can. But they still have to change it. We have never functioned bas= ed off of "there will be plenty of time for library writers to adapt&q= uot; and I don't see why we should start now.

So if we need to provide a way of users doing this explicitly, the unde= rlying implementation need not act as a function as we know it. If the curl= y braces are too much to demand, we only need to provide a way of implicitl= y converting a parameter list into a struct which can be constructed in a n= ame-based manner.
Since I don't think we need that, I think ever= ything should stay the same and leave named parameters purely as an interna= l compiler thing.

Though we still have to force them to work in a certain = way because instruction ordering needs to be consistent.

void f(int a, int b)= ;

int x =3D 0;
f(.b =3D ++x, .a =3D ++x);

Does 'a' get given the value 1 or 2= ? The approach used by compilers will need to do this consistently, and thu= s we are pinning them to an implementation. While we're doing that, bei= ng able to call
f(.a=3Dsome_expen= sive_function(), .b=3D.a);

Might = be useful to someone out there.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPUyyJm= 5RTxkhd7EszyoQ56hpo9sv5JUnja5N3n8_WxaQ%40mail.gmail.com.
--000000000000b84ab4057493d5b1-- .