220 39934 article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Named Parameters for C++ Date: Mon, 20 Aug 2018 00:25:06 -0700 (PDT) Lines: 294 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_17_955062732.1534749907064" X-Trace: blaine.gmane.org 1534749786 3345 195.159.176.226 (20 Aug 2018 07:23:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 07:23:06 +0000 (UTC) Cc: mihailnajdenov@gmail.com, bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBVGZ5HNQKGQEPHYG6MI@isocpp.org Mon Aug 20 09:23:02 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1freWh-0000hY-1u for gclcip-std-proposals@m.gmane.org; Mon, 20 Aug 2018 09:22:59 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id 79-v6sf1617282ybl.19 for ; Mon, 20 Aug 2018 00:25:09 -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=5zo3C34sD4OoedD4OoZwLzKkDyAhr3LW96un4h0pClc=; b=Cv7Rd6EgkIkjlLTndRMWYvhM4CXp5eryTTX7NLRSfKVXiGNMstLn2pvW3PEIfSGqqt Px4h2/Xs/nPCj71LQW0n+gRydRIFZUhNpVwDl3eTAU9oKlX119bhA3GADOSOyLvskGo/ n0OaDgXCCAMSSUoujMlwkLD4g0WYQw9ZTMk6iw4I8YPNlYrGdwdXfpsZyCqcCUw6tf2v PAStcVKKO4p/qcJr57Km/Cn33GTlS1QUyiqdNpx/aunmQHZXxc7jpXn4zgsk5/za9qhz Y/qm68CMXopYi5AMUrmxJDDWTwn0h04SEmwtSUBs+pkYZZWVCzoFJFQN5cc5n2iLiBMO WXcw== 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=5zo3C34sD4OoedD4OoZwLzKkDyAhr3LW96un4h0pClc=; b=VcZTrwcKd5roiS7dc2WDVJ6jfdcmeum4aI0MwNFUG4zp/PoDPSgrS00rCLaZ5zfFLz 1PpyWbl4wy75ONEnXsEWmdIlWXS1qfhPmak2KaEXNJT0kCTSkY8g+ko7P+CBHeU73C/Y SeyyuqXKpqgizvTYp1VqAMKceP6GuZgXRuvVTfhkSLCFDZc1x9Ispf8uTzue90EDSPSG Txho/NmOrOCCIYFYsSe2GsWDvdCQMLcytKufYy+V4bR6SRRNsEYqNB7girBx+VZ2fxZT d8fJQRXNEoQrQOUszZF3e0Q7vvGOCRg66f/skDqmj6bXR2K0GJZcCxO1zO6JKJrkpN6+ ylww== 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=5zo3C34sD4OoedD4OoZwLzKkDyAhr3LW96un4h0pClc=; b=emQ11JglphsF3s9B6eWqbEsno2EZTTM5Ks6ySnHrjIYyhfROY4aOEGzBGFgrdDQLD2 Vmln3KlNxDGXBYJ9ViiM2LdRe9t0YKhcsHAlCUZ2tL0YF+zZRJoX+PhFg33q1zDHRQ7H PGudGQyktOSZWdF5bWY8a3f6+N4iztEg/Y7xMOLtpE3FyY8F3IOvxBg0y5bXvKaumlEp BlFGXK5AK/BAK1YvNTZRBStqiRkvJktjc+YnMIeqfvqLHg0xQtNCGtfe8QB3lea99z7I NIoQTfX+dDj/c3Il8WaPVCZ/iu3rQi8hMpuv9F8Rfnbn7b+FGefOgpEL/XxXUJGYqbjJ cNMQ== X-Gm-Message-State: AOUpUlFNt9guXX10FVMIOHquW8mMkSG5cMp4oPgO3lYvkrxUCbKH2jA3 f7dodXRNJTZnyXpIpfT69pGe2Q== X-Google-Smtp-Source: AA+uWPw208PthGcyAMknln2dPSQFcmn7iSo2My11foIfNsoITdp9cXefpY3fhm4Alat+s1ife+GyDg== X-Received: by 2002:a81:893:: with SMTP id 141-v6mr14384510ywi.129.1534749909024; Mon, 20 Aug 2018 00:25:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:504d:: with SMTP id e74-v6ls1167670ybb.20.gmail; Mon, 20 Aug 2018 00:25:07 -0700 (PDT) X-Received: by 2002:a25:2483:: with SMTP id k125-v6mr92694ybk.5.1534749907714; Mon, 20 Aug 2018 00:25:07 -0700 (PDT) In-Reply-To: <01a106d3-cdaa-e348-2275-4222eed34dda@wanadoo.fr> 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:39934 Archived-At: ------=_Part_17_955062732.1534749907064 Content-Type: multipart/alternative; boundary="----=_Part_18_79771036.1534749907064" ------=_Part_18_79771036.1534749907064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, August 20, 2018 at 12:21:11 AM UTC+3, Vicente J. Botet Escriba= =20 wrote: > > Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9cr= it : > > > > On Sunday, August 19, 2018 at 7:46:58 PM UTC+3, Vicente J. Botet Escriba= =20 > wrote:=20 >> >> Le 19/08/2018 =C3=A0 15:04, mihailn...@gmail.com a =C3=A9crit : >> >> >> >> On Sunday, August 19, 2018 at 3:26:12 PM UTC+3, Vicente J. Botet Escriba= =20 >> wrote:=20 >>> >>> Independently of the language feature, using a tag type allows to=20 >>> transport the tag between different functions. In addition, you cannot= =20 >>> change the class constructor name, so you will need a tag to be able to= =20 >>> overload it. Take for example the in_place_t tag.=20 >>> >> >> I have thoroughly explored that idea a month back:=20 >> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/tPtdQE2GXb0/4= OjT5Z4pBQAJ >> >> Feel free to comment there, I am undecided on the topic.=20 >> >> =20 >> >> I'm not sure yet we need some syntactic sugar for this tag dispatching= =20 >> feature neither. >> I'm just trying to separate the named parameter part from the overload= =20 >> part as orthogonal features. >> You go too far for my taste in your proposal and you propose to have all= =20 >> at once. I'll be against such a feature. >> > > Can you elaborate a bit more, what are your expectations and where should= =20 > a line be drawn? As you can see in the comments to the post, there are=20 > similar concerns. > In any case it is not a proposal, but an investigation. It is clear tags= =20 > have overlap with strong names, and if we can get an attractive=20 > proposition, based on tags, we can mark at least one part (the harder=20 > part?) of the named arguments equation "fixed".=20 > > =20 > I would like to see the two features proposed independently.=20 > > I see more added value for weak named parameters that are optional and op= t=20 > in on the author side (as the workarounds are not always friendly) than t= he=20 > strong named parameters that can be used to overload function or=20 > constructors and that are not optional (as tag types are an almost friend= ly=20 > library solution, as the standard library has showed already multiple=20 > times). > This is also my PoV in general, especially with more friendly tags.=20 However, many people hate the idea names will be for weak only and they are= =20 left to use workarounds for overload resolution - after all, they consider= =20 names the correct way of handling this. The second issue is, neither tags nor named functions are perfect=20 solutions. Tags are a technically a working solution, but they don't convey= =20 the same meaning as label would.=20 Natural naming like for:, to:, with:, if:, relativeTo:, ignoring:,=20 including:, are pretty much unattainable for tags, both for the words that= =20 can be used and the lack of semicolon to give context when reading the code= .. If we say "just use tags", people will still demand strong names, this is= =20 what I am trying to say.=20 Sadly, strong names do not eliminate the need for tags!=20 To still have tag as an idiom AND strong names, this is probably too much,= =20 but I might be wrong -=20 after all if we eliminate static/free functions as constructors, it will be= =20 a massive win, even if there are some use for tags left. This is what I mean by "where should we draw the line".=20 =20 > > 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/a1ea778c-4b2c-4af0-90ac-0ba0792cc439%40isocpp.or= g. ------=_Part_18_79771036.1534749907064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, August 20, 2018 at 12:21:11 AM UTC+3, V= icente J. Botet Escriba wrote:
=20 =20 =20
Le 19/08/2018 =C3=A0 19:22, mihailn...@gmail.com a =C3=A9crit=C2=A0:
=20


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 th= e 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

<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
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).
=
This is also my PoV in general, especially with more friendl= y tags.=C2=A0
However, many people hate the idea names will be fo= r weak only and they are left to use workarounds for overload resolution - = after all, they consider names the correct way of handling this.
=
The second issue is, neither tags nor named functions are pe= rfect solutions. Tags are a technically a working solution, but they don= 9;t convey the same meaning as label would.=C2=A0
Natural naming = like for:, to:, with:, if:, relativeTo= :, ignoring:, including:, are pretty much unattainable for tags, bot= h for the words that can be used and the lack of semicolon to give context = when reading the code.

If we say "just use ta= gs", people will still demand strong names, this is what I am trying t= o say.=C2=A0

Sadly, strong names do not eliminate = the need for tags!=C2=A0
To still have tag as an idiom AND strong= names, this is probably too much, but I might be wrong -=C2=A0
a= fter all if we eliminate static/free functions as constructors, it will be = a massive win, even if there are some use for tags left.
This= is what I mean by "where should we draw the line".=C2=A0

=

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/a1ea778c-4b2c-4af0-90ac-0ba0792cc439= %40isocpp.org.
------=_Part_18_79771036.1534749907064-- ------=_Part_17_955062732.1534749907064-- .