220 39933 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named Parameters for C++ Date: Mon, 20 Aug 2018 08:18:42 +0200 Lines: 395 Approved: news@gmane.org Message-ID: References: <1708615.QdClGnisbJ@tjmaciei-mobl1> <60fba045-252b-486e-92e0-03c08b6d5a35@wanadoo.fr> <1925737.EHUJpxQoH7@tjmaciei-mobl1> <4df1f86f-cdee-5275-bdd1-b53f2f10bef8@wanadoo.fr> <7e07b857-8be0-f0b4-79e2-32d0f2d8e823@wanadoo.fr> <7d28cd24-b43d-4e24-876b-a04adcbbe867@isocpp.org> <19c6eb56-2188-b849-6ea1-87b37cb546de@wanadoo.fr> <3fc9fb1a-8803-4bcf-b928-c855e76f880e@isocpp.org> <01a106d3-cdaa-e348-2275-4222eed34dda@wanadoo.fr> <67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3DFBE57ABCFC7BC72C9C125A" X-Trace: blaine.gmane.org 1534745811 26644 195.159.176.226 (20 Aug 2018 06:16:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 06:16:51 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: mihailnajdenov@gmail.com, bop@gmb.dk To: std-proposals@isocpp.org, Nicol Bolas Original-X-From: std-proposals+bncBDH67CONY4PBBUF25HNQKGQEFDOGY3Q@isocpp.org Mon Aug 20 08:16:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr1-f72.google.com ([209.85.221.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frdUc-0006p9-Qx for gclcip-std-proposals@m.gmane.org; Mon, 20 Aug 2018 08:16:46 +0200 Original-Received: by mail-wr1-f72.google.com with SMTP id k44-v6sf2506748wre.21 for ; Sun, 19 Aug 2018 23:18:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1534745936; cv=pass; d=google.com; s=arc-20160816; b=HLIAhdh0A275c6QtOvSjxgxGA6VYfdjtI75yWMRDL0xK1PrbU2rQmkS5sxUEW/imki 9e0sSnkxBMt4EG2Url+kEc1dmHDQSypmsJJMgd53/c0/7gKz+XsBsNN0gM+gZVKuoli2 3JTDAe/ux1s5GDUvQwJV1W6zUj8zYyIohJpSOew5Osoenvt1icSD32Df14qF9ToOkwB+ cXHemkqoyxRlQdWR5FmGUFxcA7PNam7C/vdp0QJrEGcWNzwO81xMTHH27z5RwNux+3io Un8S3IPj+wrFtpLSxAEgbhz/TxnL7RS5/Z6RqmTOse/mhbitodohNpaR64tHUSpYhE+x 9IdQ== 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:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=t2F6TZGEr0McKt3zCgYkXxdis0dmQOEx6KoPs66mF2s=; b=pwRbK6+GNqZhQYAlQE2LmbGfYUi+fOrFpI+c/0uBo2O1rMrfMypdihAgJnvV/IiPv/ GwhvZIa3HMfTKdiVFb8L/IqVRRtLYLFn+pNCCw/GGczHY/Zx9LjFu/ttyqQ0Mne4Es1/ 1VIqpW59grwxJvca2GvzFXjQYB6jeXhCwhaiOQEovkNYipecCG4C6eprEQIaReU0FDAj Zp3PsjCnOGMs2Nys3CiZeOsTtKDFzHXXq0jgIsc6FBrJGGtA08gs/KFzXYdwI10dAzu7 da81Pz5T5BsxbfeFUXngbqVr1KNirmZIdT/DgZUw1aaKiRxXgvINVjTzW2Y1WpyiQ9Ff jiHg== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language: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=t2F6TZGEr0McKt3zCgYkXxdis0dmQOEx6KoPs66mF2s=; b=zyV+CMsTNDaW7Dr9/+ynQXhxzXBhM3qTN3lmA7bu1Pa94hkW0WAFVP0DpqpSXc3Wqp 8H/2dPsx67jrMrvYuhLtW5Osy2dLjWgnWdcWlQUghHvr/tcSkvcHASSIL6QJNkj0KGL0 NYbO6b633slD2VLNQtvcTC6b2i7C/kBiHoqjlA+0PNgtBFCPaymxmywcSd/ouawrm0yE IbhPw44nclvsyHa4U+/LdPoP/W4jWkQ/pEX+/aBZGjbGSStr6h+vT3p91zzl+Y+Czeto plItLMwZrh54dKvBBT33hE5QsuJ3qXWcklNMhRAD29Sk+K/voaN5/rbZ1WgvKl4iPqBD CiUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :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=t2F6TZGEr0McKt3zCgYkXxdis0dmQOEx6KoPs66mF2s=; b=opdgUtlOzXV0EU6HxCS7LUI1JnOBD2YkvGWB7j2TTlch75OcxLFJBWnpjVA6FpAvG7 Mwf5EtuQ5wc8PIA+BsMtJ47vdG3uomrtqDTmzTuPrD1g1i4Ra6ij0D3y8/vJMrgvvjcM nOE/iO+6KxML8MynbcA9LUPibMptydyRRo6A+mmbGraGDYCoC3IP0B8MMDyYO8EBmPmO n6kyG+LOSsm0zivR5tUX4lk8hvq8aCYYs/7IKhvYDxpat7Rue1sBMAsx0R2HaHH3jbnm qody8zfEyh9dBSplK2Y3TC8oaUoVeXe6o0wW8oKBIZI/xCRTrlA9GlLVE8qIrRGQ+nLL X-Gm-Message-State: AOUpUlF6AZIBcbHaX+NzjztX0AfTsAtfcwmO+mq2dX6eXgOoNQKcX+Mv LIqp8OgCHXlZ1FKs6v4Xqvo= X-Google-Smtp-Source: AA+uWPyVxq8uUFBB0X+lf1dmlUWZoJv2koN9bqo5pgdlo5f+rb4mtdooMjVxzbChx86XggbmdZG0gQ== X-Received: by 2002:a1c:3091:: with SMTP id w139-v6mr3657272wmw.7.1534745936557; Sun, 19 Aug 2018 23:18:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:ad2e:: with SMTP id p43-v6ls188039wrc.12.gmail; Sun, 19 Aug 2018 23:18:55 -0700 (PDT) X-Received: by 2002:adf:c4c9:: with SMTP id o9-v6mr5932994wrf.173.1534745935850; Sun, 19 Aug 2018 23:18:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534745935; cv=none; d=google.com; s=arc-20160816; b=Jl/IThrtPOQ3iQxZerMW1fBzJv8JPYzvyDd4pirfUgd++6PaQC3v+cpGOCS6ESo6bp QMiKQefFEoxh0EQ7RRWGLkPaXXRfk/pjVzwkrMW+HqfpUaFB5UUENN9fCjZ1nhkO2ROX 5EoaXhC6Sw5vjHsvCfp1TwglnzZq0q/AWfU+EBHJTGZGeAwFsqFRwvUpjKeenn9geazU Y0t+C19Y759z7ZvAqBxaUYAMVL7nBSop4BYoCXngpfjDsZ+rQcy3x4AZSmc0o8kShRi4 mXDW9ks5UgP4ywrn+XfP3GAwDfjmWvWvwvA9hkZ97c+bUghDDhk1Hm2uBl+P+wrtnZVO V3bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=PNiNf2rifikSi8wy7OGaZue7SsGBgjXg3vbe/rj4+nE=; b=PsF9zgmXKNeSfO5Lu4aGSiAovyHguY9j6+Fnk1bTfa7Nq6veMyQR9SFxwmfz/si0Et 1jsnxtOsQHZu8S1OMvEbOSJXsgx4EmVvXyuI/PDXmX3kub3ZfHoof1ETO1eWUBdbBHdK 531Cv/aKwY4bhibH8hPl/ySpsuWeI0LVS3hVGWg0IznMHd2EY1XptvI+InCkNC9Hdomx MejwY4UZeFhVOrPypVSM70RiOaO4xActfmxy6bOfPymKC0IfMJIFJ5otHKTMAecnEMrv OdvQSgOxNyHnM0oCREbTm2VRAc+Ds4714AvohN8MWZN6MDxkizj+OfSwThUrsIJT+MXm qR9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123]) by mx.google.com with ESMTPS id a8-v6si6554510wrq.395.2018.08.19.23.18.55 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 19 Aug 2018 23:18:55 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.123; Original-Received: from imac-de-vicente-botet-escriba.home ([86.253.39.2]) by mwinf5d36 with ME id RJJj1y00B02nUfq03JJn8l; Mon, 20 Aug 2018 08:18:55 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Mon, 20 Aug 2018 08:18:55 +0200 X-ME-IP: 86.253.39.2 In-Reply-To: <67ab8a8c-4a0c-4b4f-8ea1-56822e660517@isocpp.org> Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:39933 Archived-At: This is a multi-part message in MIME format. --------------3DFBE57ABCFC7BC72C9C125A Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 19/08/2018 =C3=A0 23:53, Nicol Bolas a =C3=A9crit=C2=A0: > > > On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet=20 > Escriba wrote: > > Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3= =A9crit=C2=A0: >> >> >> On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet >> Escriba wrote: >> >> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit=C2= =A0: >>> >>> >>> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. >>> Botet Escriba wrote: >>> >>> Independently of the language feature, using a tag type >>> allows to >>> transport the tag between different functions. In >>> addition, you cannot >>> change the class constructor name, so you will need a >>> tag to be able to >>> overload it. Take for example the in_place_t tag. >>> >>> >>> I have thoroughly explored that idea a month back: >>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtd= QE2GXb0/4OjT5Z4pBQAJ >>> >>> >>> Feel free to comment there, I am undecided on the topic. >>> >> I'm not sure yet we need some syntactic sugar for this tag >> dispatching feature neither. >> I'm just trying to separate the named parameter part from the >> overload part as orthogonal features. >> You go too far for my taste in your proposal and you propose >> to have all at once. I'll be against such a feature. >> >> >> Can you elaborate a bit more, what are your expectations and >> where should a line be drawn? As you can see in the comments to >> the post, there are similar concerns. >> In any case it is not a proposal, but an investigation. It is >> clear tags have overlap with strong names, and if we can get an >> attractive proposition, based on tags, we can mark at least one >> part (the harder part?) of the named arguments equation "fixed". >> > I would like to see the two features proposed independently. > > I see more added value for weak named parameters that are optional > and opt in on the author side (as the workarounds are not always > friendly) than the strong named parameters that can be used to > overload function or constructors and that are not optional (as > tag types are an almost friendly library solution, as the standard > library has showed already multiple times). > > > The problem with having them be independent is that they're /not/=20 > independent. They're both playing around in the same space: invoking a=20 > parameter's name when you call the function. > > The first question any named parameter proposal has to answer is=20 > whether to rely on the existing parameter name infrastructure or to=20 > use a special way to define them. There are arguments for both weak=20 > and strong parameters to want to have syntax to declare named=20 > parameters on a function. This is because, by having users rely on=20 > them to some degree (even if mis-matched naming is just a warning),=20 > you are making those parameter names part of the interface of the API.=20 > And that's different from how parameter names have been treated in the=20 > past. I'm not for strong named parameters. For me, this is a disguised form of=20 mixing weak named parameters and tag dispatching. This is why I believe=20 the features are independent. Now you can put them together and obtain named parameters and tag dispatch. > > If you try to develop weak and strong parameters completely=20 > independently, then what you can end up with are two proposals that=20 > provide completely different ways of declaring such parameters. And=20 > considering all of the stuff that we keep cramming into function=20 > declarations these days, giving parameters /three names/ is utterly=20 > absurd. Even if you forbid weak parameter names on functions with=20 > strong names, that's still 3 separate syntaxes for declaring parameter=20 > names. If we want weak and strong named parameters and don't see another=20 solution than having two syntax :( I don't believe that we want non op in named parameters, so each one of=20 the weak/strong alternatives would need a specific syntax. > > So I don't think it's reasonable to develop the two proposals=20 > completely independently from one another. They should at least be=20 > developed with the knowledge that the other is a possibility, and with=20 > syntax that can reasonably fit together. Maybe you are right, but I would like that the proposal are clearly=20 separated, so that we can be against one from or the other. > > Lastly, it should be noted that tagged dispatch doesn't help with what=20 > I will refer to as "mega-functions": functions that take stupidly=20 > large numbers of relatively independent parameters, but for some=20 > reason don't want to take them as a convenient aggregate. This is a=20 > use case that some people want to support, to avoid conceptual=20 > two-stage construction. IMHO, this case is covered by weak named parameters already. If you accept that your signature changes and require that the argument=20 must be named, strong named parameters could as well cover it. If you don't accept that your signature changes and require that the=20 argument must be named, weak named parameters + some static analysis=20 tool (as clang-tidy) help could as well cover it (but not that the=20 syantax will be already defined by the standard). Maybe we need strong named parameters that don't change the signatures=20 as well ;-) Vicente --=20 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 e= mail 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/e97ada03-8b7c-39c3-cc85-514a3b67091d%40wanadoo.f= r. --------------3DFBE57ABCFC7BC72C9C125A Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 19/08/2018 =C3=A0 23:53, Nicol Bolas = a =C3=A9crit=C2=A0:


On Sunday, August 19, 2018 at 5:21:11 PM UTC-4, Vicente J. Botet Escriba wrote:
Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit=C2=A0:


On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba wrote:
Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit=C2=A0:


On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba wrote:
Independently of the language feature, using a tag type allows to
transport the tag between different functions. In addition, you cannot
change the class constructor name, so you will need a tag to be able to
overload it. Take for example the in_place_t tag.


Feel free to comment there, I am undecided on the topic.=C2=A0

=C2=A0
I'm not sure yet we need some syntactic sugar for this tag dispatching feature neither.
I'm just trying to separate the named parameter part from the overload part as orthogonal features.
You go too far for my taste in your proposal and you propose to have all at once. I'll be against such a feature.

Can you elaborate a bit more, what are your expectations and where should a line be drawn? As you can see in the comments to the post, there are similar concerns.
In any case it is not a proposal, but an investigation. It is clear tags have overlap with strong names, and if we can get an attractive proposition, based on tags, we can mark at least one part (the harder part?) of the named arguments equation "fixed".=C2=A0

I would like to see the two features proposed independently.

I see more added value for weak named parameters that are optional and opt in on the author side (as the workarounds are not always friendly) than the strong named parameters that can be used to overload function or constructors and that are not optional (as tag types are an almost friendly library solution, as the standard library has showed already multiple times).

The problem with having them be independent is that they're not independent. They're both playing around in the same space: invoking a parameter's name when you call the function.

The first question any named parameter proposal has to answer is whether to rely on the existing parameter name infrastructure or to use a special way to define them. There are arguments for both weak and strong parameters to want to have syntax to declare named parameters on a function. This is because, by having users rely on them to some degree (even if mis-matched naming is just a warning), you are making those parameter names part of the interface of the API. And that's different from how parameter names have been treated in the past.
I'm not for strong named parameters. For me, this is a disguised form of mixing weak named parameters and tag dispatching. This is why I believe the features are independent.
Now you can put them together and obtain named parameters and tag dispatch.

If you try to develop weak and strong parameters completely independently, then what you can end up with are two proposals that provide completely different ways of declaring such parameters. And considering all of the stuff that we keep cramming into function declarations these days, giving parameters three names is utterly absurd. Even if you forbid weak parameter names on functions with strong names, that's still 3 separate syntaxes for declaring parameter names.
If we want weak and strong named parameters and don't see another solution than having two syntax :(

I don't believe that we want non op in named parameters, so each one of the weak/strong alternatives would need a specific syntax.


So I don't think it's reasonable to develop the two proposals completely independently from one another. They should at least be developed with the knowledge that the other is a possibility, and with syntax that can reasonably fit together.
Maybe you are right, but I would like that the proposal are clearly separated, so that we can be against one from or the other.

Lastly, it should be noted that tagged dispatch doesn't help with what I will refer to as "mega-functions": functions that take stupidly large numbers of relatively independent parameters, but for some reason don't want to take them as a convenient aggregate. This is a use case that some people want to support, to avoid conceptual two-stage construction.
IMHO, this case is covered by weak named parameters already.=C2=A0
If you accept that your signature changes and require that the argument must be named, strong named parameters could as well cover it.

If you don't accept that your signature changes and require that the argument must be named, weak named parameters + some static analysis tool (as clang-tidy) help could as well cover it (but not that the syantax will be already defined by the standard).

Maybe we need strong named parameters that don't change the signatures as well ;-)




Vicente

--
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/e97ada03-8b7c-39c3-cc85-514a3b67091d= %40wanadoo.fr.
--------------3DFBE57ABCFC7BC72C9C125A-- .