220 41157 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Function Parameter of Struct Type -> Named Parameters Date: Fri, 30 Nov 2018 16:11:21 +0000 Lines: 114 Approved: news@gmane.org Message-ID: References: <20181129060523.GA21632@noemi.bahnhof.se> <20181130020338.GA2787@noemi.bahnhof.se> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007bb612057be40d56" X-Trace: blaine.gmane.org 1543594170 7324 195.159.176.226 (30 Nov 2018 16:09:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 16:09:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBNOCQXQAKGQEXDIACMY@isocpp.org Fri Nov 30 17:09:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io1-f70.google.com ([209.85.166.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSlM4-0001lB-8X for gclcip-std-proposals@m.gmane.org; Fri, 30 Nov 2018 17:09:24 +0100 Original-Received: by mail-io1-f70.google.com with SMTP id s25sf5940674ioc.14 for ; Fri, 30 Nov 2018 08:11:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1543594294; cv=pass; d=google.com; s=arc-20160816; b=BF9ITpi9oau7yKogGlLnFKFdoWICSI08Z5IgC2F4gKZoGjV5uap18xkj2vwkQOaZtt ajGEmIbaDWd+gDH8PN57YHKqEqMFvOV1eK1PpYr3TAO5gV5WhPqaj3QiUWtLvng3VWiD BhH1/j43y+O/bNyk14zzeiW2ShrtDVoq7Nt/5s/lRBWeQr5ZDTV7/YllIgKCuI0tYoPx uUD1TAezEG2WTnOnBGYAMb8LDltxwDmjeraEh8ACWqwbByX7OsZB1JtBbUsp5x30waRE ew8izhVRApj7ucA34yhBb7B+CRCJuLidU3Eusb0MWXJEyI5IzgBrVqW/G4PwHzNIyBUI AOxg== 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:dkim-signature; bh=PjiTMzNGbC5PSwQY0UHR7avdTJ9tZKEVYBqVIuOAbVA=; b=PQnzNjMEEN5wpzhEHW30LtktDwLSjSfz8KIWSvF7Q60TteqPhzlhZGd5/IARXSTp4l t98J4eRjUd9KAIhmyJDe9DqfdynaXU0Yfs64xoYlonQqRtr1mnNc8WVSBKRjYrhLzpqk 0wmG/06HherdvJvvKie2ufA4+t4Ng1Wl4rLpw/ocSTHPpILBdAMwbmwFrYsqzH5tncnw 83mYVfmPmsYT74//07Ej71AbjRBs+NhwcGyPWMHdH2l5AgwsdpfR1eCpeVWWV6Uu4c/j Re7SWCJ+mnUcX/cj1H8sqhBaYX4K957AfMonzuEqZDtJcolA1EliryidbKN/W8Wj364x LYUQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Oi6krouR; 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=PjiTMzNGbC5PSwQY0UHR7avdTJ9tZKEVYBqVIuOAbVA=; b=ykugdHtIWYVv+pIHrrV/EPbYXsWAWCq9KD5w6QQADkkixZC/PknvF0Rqud0fyAAFyW y6kkCppYQngwmMPFy/0o2640rrau1kpgdRp7GzrX4Mx7FTzIGSkmuiBJiToGiXstZY9R cVBrypnCJiApR30fD0CSDWiNNM933/0tzJlvdiSP0JGao1LA8dGdAH5MkX9HyUJGv9l+ qo0CZZ5UyWY6vhCvU4bG2vKEQJxK5XerZBPLyc34O6xUUsSRAOTJ/ni+7ETSg6bPiCS3 xpBkI2pNt5ktOF3MSBfSjavWgnlvvHVsCv8/+MVDbjosztBCT9P2QwKvSbLysHGL3uD7 YBCw== 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=PjiTMzNGbC5PSwQY0UHR7avdTJ9tZKEVYBqVIuOAbVA=; b=Osp5QeU3iirz+NOLDO8E07wgDofvor9aIh56BOVkUOpqiFhL/Qn9s5C1OYErV2lrzt xrU3zHNeDi+c5I+wESjEvbPvU440h0FiFsPWxDnsSKJJSVFHZTn/jDP95Kc6oiMNUqg8 NMSl3XybCCOR+0Os6czyQGOPnGl0goTwk/dKChDPYA4ZZTuIvZsOInR4glmBASPW3eSY ont88J5aGn1RqjhbBfURqcBsysKYSgUzm+1npXJ27nXiKdXAMMt7n/ZOdFTotJdy0ffL copEyjGRRODEIO77t08w5ydgczAQWyq91oulaxwmNSDbeSJOl9dQc072HFPUPKs/gTiu RvBw== X-Gm-Message-State: AA+aEWabNuNNXbKBwtIrWFQoe8Nx2Et6ejSLgAjxEBJma9VbgjHbIVX8 QHX9+eMFO5OpxQDq/VhbzFVAVw== X-Google-Smtp-Source: AFSGD/W07ayOBVPUr6Un6CIpUVr3xi+qBMVshNe1ZB+xikkO53fO/D4dEiFJAUCZIuQHt/yVQueEog== X-Received: by 2002:a24:3653:: with SMTP id l80mr4902510itl.3.1543594294307; Fri, 30 Nov 2018 08:11:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:ad0:: with SMTP id 199ls1782424itw.1.gmail; Fri, 30 Nov 2018 08:11:33 -0800 (PST) X-Received: by 2002:a24:6b90:: with SMTP id v138mr4588886itc.86.1543594293070; Fri, 30 Nov 2018 08:11:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543594293; cv=none; d=google.com; s=arc-20160816; b=tHFFOjYJMqKK1LmD+dujyHZ7myT0w9oRqgMmFbxnAKWWcLMbA11CsFstpgmUOt8+Z0 aqFfkRy8s7kpKVliUYZOqnXxyTvJ4++WYYb3dFJ93HzNU4c7Fn8reRYPyw1t2pwAh37N 3yvz3nXlsZsjksu9+YIdG7aGnK3rFk1cATAKyTRP32/xgaEWeH8BIJwW8YltzO2Ohzmt yhNDYY9p0Ose/7cxh35LUoqN6+buGA3BSXRV+qo+wuT1Bi6y7MaGMDPeERzXfljtCeWx Dg5ZdVSxUuIw89PJKiqELl+JhyT5MyZEpm64FNJws9fXgrTqtFqnIk/5faGM01NW64uN Y2Mg== 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; bh=3t8HPZ91n+6/AalW/g1aTO2DtcFi0+HZJRfeyGRjneE=; b=nJhKgmDgVV0Gimn1q5+5qEuDv4CVuzoAAgWObDsMLCDTkHBcqhwnaPFHZJCfxCkyi5 8xCJfq8Mv3ZTHj0xPzIcp243gnRMEnOR1JVTUzXr9b127dzpkedHnDpiM6WGnD7dkCja pGjRJk9/FQZ9FzchGaZuGT70226YaW8UKqLYILYsv4CpibuKRNfQza21QaJhYXV4Sr0h P7LXK5mo+dd6WcoFRbvIc5BMW1snbxVdjEOgQYaODQrMNlBILMff2GmOxvXa4eiO2RhW f1Fb7vFkFLhf8K3yohzAml/8xDiuF0QQ6Q31gBq7HXOGmOgb6aaMoBzcsIYYFCYYrBkq u90A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Oi6krouR; 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 y8sor2404082iof.82.2018.11.30.08.11.33 for (Google Transport Security); Fri, 30 Nov 2018 08:11:33 -0800 (PST) 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:a5e:c24a:: with SMTP id w10mr5445439iop.178.1543594292523; Fri, 30 Nov 2018 08:11:32 -0800 (PST) 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=Oi6krouR; 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:41157 Archived-At: --0000000000007bb612057be40d56 Content-Type: text/plain; charset="UTF-8" On Fri, 30 Nov 2018, 16:06 Hyman Rosen On Thu, Nov 29, 2018 at 9:38 PM Jake Arkinstall > wrote: > >> One thing I like about the struct idea is that it gives the control over >> named parameters to the API author, not to the user. >> > > I think that's a bad idea. The API author should be supplying good > parameter names just like they supply good function names, good class > names, good > enumeration literals, and so on. Just because it does not matter now (and > that's not really true, because functions should be documented and the > documentation should be describing the parameters, so they should already > have sensible names) is no reason to allow it to continue not to matter. > > >> Another benefit I see is that we don't need a change to function >> mangling, whereas function calls with parameters of the same types but >> different names would require such a change. >> > > No. Named arguments (in my preferred and correct Ada style) are handled > by the compiler without any ABI or mangling changes needed. You cannot > overload based only on different parameter names. Just as now, multiple > function declarations with the same function name and parameter types will > declare the same function, even if the different declarations use different > parameter names. > > Overload resolution at the call site can use named argument association to > help pick a function to call, but parameter names do not generate different > functions > Both of these points are nonetheless opinions. The notion of allowing overloads of the same types with different parameter names is very much on the table - again, we have no poll results and no consensus, so the only thing we ever manage to obtain on these discussions is knowledge that everyone wants something different. > -- 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%2B0CCP5Zzz5xxvbaT0Wr09EQnq75Wq4xWtsPsv-e%3DO%2Ba9G_WQ%40mail.gmail.com. --0000000000007bb612057be40d56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, = 30 Nov 2018, 16:06 Hyman Rosen <hyman.rosen@gmail.com wrote:
<= div dir=3D"ltr">
On Thu, Nov 29,= 2018 at 9:38 PM Jake Arkinstall <jake.arkinstall@gmail.com&g= t; wrote:
One thing I like about the struct idea is that it gives the control = over named parameters to the API author, not to the user.

I think that's a bad idea.=C2=A0 The API author should = be supplying good parameter names just like they supply good function names= , good class names, good
enumeration literals, and so on.=C2=A0 Just bec= ause it does not matter now (and that's not really true, because functi= ons should be documented and the documentation should be describing the par= ameters, so they should already have sensible names) is no reason to allow = it to continue not to matter.
=C2=A0
Another benefit I see is that we don&= #39;t need a change to function mangling, whereas function calls with param= eters of the same types but different names would require such a change.

No.=C2=A0 Named arguments (in my preferred a= nd correct Ada style) are handled by the compiler without any ABI or mangli= ng changes needed.=C2=A0 You cannot overload based only on different parame= ter names.=C2=A0 Just as now, multiple function declarations=C2=A0with the = same function name and parameter types will declare the same function, even= if the different declarations use different parameter names.
Overload resolution at the call site can use named argument ass= ociation to help pick a function to call, but parameter names do not genera= te different functions

Both of these points are nonetheless = opinions. The notion of allowing overloads of the same types with different= parameter names is very much on the table - again, we have no poll results= and no consensus, so the only thing we ever manage to obtain on these disc= ussions is knowledge that everyone wants something different.

--
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/CAC%2B0CCP5= Zzz5xxvbaT0Wr09EQnq75Wq4xWtsPsv-e%3DO%2Ba9G_WQ%40mail.gmail.com.
--0000000000007bb612057be40d56-- .