220 38253 <4eb665e1-97fa-4e1a-93e5-e446b5145866@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Simple, terse universal forwading for the next decade Date: Mon, 28 May 2018 23:06:21 -0700 (PDT) Lines: 194 Approved: news@gmane.org Message-ID: <4eb665e1-97fa-4e1a-93e5-e446b5145866@isocpp.org> References: <80548757-8a42-499a-bf15-3670b2727082@isocpp.org> <8d3b34de-c06a-4083-bb0c-8e2c7482abf0@isocpp.org> <9930a9dc-b998-4431-a159-6d72d1d9b2ff@isocpp.org> <8e1c6607-a92d-496b-aad1-e992e049a748@isocpp.org> <2f782c2d-e89c-4d8b-8ef6-372c00e62ab1@isocpp.org> <93ee46a2-1469-48ae-b931-c060946f38d5@isocpp.org> <609892ba-f717-4458-b9e3-c5975378ad29@isocpp.org> <4d68237c-077a-4408-abf1-5f9670311f71@isocpp.org> <70fe7dc7-b8a6-4498-9aa6-f88e6af06506@isocpp.org> <0c4f8aa4-6b4f-4fe3-a02a-ef33eae990a8@isocpp.org> <285d0120-bf49-4b98-9ebd-8ec71c3f275a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_36272_1107401589.1527573981928" X-Trace: blaine.gmane.org 1527573860 25826 195.159.176.226 (29 May 2018 06:04:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 May 2018 06:04:20 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBXW3WPMAKGQECIUBYOY@isocpp.org Tue May 29 08:04:15 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fNXjw-0006a4-Rf for gclcip-std-proposals@m.gmane.org; Tue, 29 May 2018 08:04:13 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id s7-v6sf9053704ybo.4 for ; Mon, 28 May 2018 23:06:24 -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=4DVUoZ/nikcf0ackgMV+Lkq9vqtq8F8PkrpXUevu/sY=; b=d0H8ZeNSzcaCDQsEgMp+yVHxjEbGh1zKr1FAr82i3wjnVG80kPnXPOe2UxyvpiVgHE H0dXZ9GaUdoiVNZMI1DQ0Po00lmuxJQ/UO7uvj9AOMVuyqDvY8kElz1X14/enb4WnLOD l/aH8T/gwsjxPlbTFVeTwg8YeCK3VVANyiv+/QFxN9LlYdDCsgFdDl2m5wnG+ZFOWiia Tw6Bz5Tg6HlmaybOIPNA/sZDLb003x0x4NOs7y/BpAohMfYw1UGnMq2KXkvCISSghEpO ErLM156ZyWRShd+S1OJg1joQWdTAYKPCnpWOIIrWviJpzrl2q4U43tSpVEylWBKgECsq WzVA== 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=4DVUoZ/nikcf0ackgMV+Lkq9vqtq8F8PkrpXUevu/sY=; b=Q0UUo9vddtdNKkOkd/7cB7daIpJfd7gKtjACtUop/QUHA+JAcZJWZQ59+5QsFC2kwe YEPTmnBcsUUtneCWh7lgAdzPjFSLuEEOrOh/KGGR2E6VNPMWrg7HFqf61iCkmbwnS1qM oZFUSvFMQKl2yDjW+0saLMgCtb+G7fBsgZIkRO96gfzmsN8SuanYK4Bj0YQYZUfnaq2l 7/yIWsZY2lj9AhdaUUAH6ogU91F92amqSBmkPCo4sw4UUMEgNtnRek6Bp1JevZl5YP8z VmCwVXIV6G9vlIch4IzfnAUx2oM5S7tJVQ3dAhtl7imMLb/QJBtzLdIivbZDmGM/d9/t vEtA== 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=4DVUoZ/nikcf0ackgMV+Lkq9vqtq8F8PkrpXUevu/sY=; b=KkPW20JBd1fSGepr1npiQ3/o+1RykPMeKiXpjHEzrb4AhpIa9FQIK5PTMRULj2Q/nq RfvVwXGRLhCFgeMReWhRuduT/ZRKjGzVx+cTk0g7Wxw/ZTYL/GNoDCVznyhJ7HbDf0t6 bf7q5bQkU/U3H6hInvFGY/piVkLxg9e1QauT/yr7YaC3TkqQUYvA7tembaSbfelmxYMG URrUpmvlSJ19zQYADQIt0e3YOe1Q7mKcpxfGDIkAKLc4ZKQRkEHtqPZ14JHs5PjhsOXu QVrOq/IoalqnZ9UPrFmZrB5eMasXcPznwlW3z8r5LgZu+HpUVtJPhem7BwYFwEjmVq9X Vt9g== X-Gm-Message-State: ALKqPweMAlHZ3Y66aIqSJIl+18pFAY1z7/9+9Qomqc4BY30PoIzEdf5X MaHANeeGt0Pnp4/m8iPqLz4ckg== X-Google-Smtp-Source: ADUXVKKeR2lvIS279b6jU/huGpqLmGO84H5KAif71ol51GnLMhptd9XvTDwjJISb+jmi3ZJfOU6mLA== X-Received: by 2002:a81:9f49:: with SMTP id w70-v6mr1149662ywg.146.1527573983711; Mon, 28 May 2018 23:06:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:4fc7:: with SMTP id d190-v6ls440720ywb.30.gmail; Mon, 28 May 2018 23:06:22 -0700 (PDT) X-Received: by 2002:a81:994d:: with SMTP id q74-v6mr476533ywg.12.1527573982478; Mon, 28 May 2018 23:06:22 -0700 (PDT) In-Reply-To: <285d0120-bf49-4b98-9ebd-8ec71c3f275a@isocpp.org> 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:38253 Archived-At: ------=_Part_36272_1107401589.1527573981928 Content-Type: multipart/alternative; boundary="----=_Part_36273_776154330.1527573981929" ------=_Part_36273_776154330.1527573981929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Richard=20 A keyword will not be a good solution for move, not better enough then the= =20 current one. I care for move as much as forward. I also feel keywords are dead-end in C++ simply by looking to many if not= =20 all newly introduced - decltype, nullptr, co_await, constexpr, reflectexpr?= =20 I know the reasons behind all these, but that do not change the fact I=20 don't like them. =20 @Nicolas and Nicol=20 You are right, I have been a bit too optimistic, but that's normal I guess. Thanks for pointing this *obvious* issue. Guess it was too good to be=20 true/possible. In any case - there are plenty of other options. That was just the best in= =20 general. I will throw at you a bunch more by the end of the day. Thanks again! On Tuesday, May 29, 2018 at 3:32:10 AM UTC+3, Nicol Bolas wrote: > > > > On Monday, May 28, 2018 at 4:20:28 PM UTC-4, mihailn...@gmail.com wrote: >> >> >> >> On Monday, May 28, 2018 at 8:50:41 PM UTC+3, Ga=C5=A1per A=C5=BEman wrot= e: >>> >>> Nicol, >>> >>> I forsee a fight to distinguish the unary && from the binary && in fold= =20 >>>>> expressions, but otherwise... >>>>> >>>> I don't think there *is* an "otherwise" at that point. If &&...=20 >>>> already has a meaning, that's the end of the conversation. Backwards= =20 >>>> incompatible changes for this are probably a non-starter. >>>> >>> >>> The "otherwise" was not meant as "I see a possibility of changing the= =20 >>> meaning of existing syntax" :). I meant that (args&&)... might actually= =20 >>> still be possible. I do think it's iffy. >>> >> >> What the problem might be? >> >> auto c =3D a&& && b; >> >> template >> auto sum(T&&... args) { >> return (args&& && ... && T{});=20 >> } >> =20 >> These will do what it's expected. >> > > Backwards compatibility is *not* about the ability to write correct code= =20 > now. It's the ability for previously correct code to *remain correct*. > > `args && ...` is a fold expression. What you want will no longer make it= =20 > so. > > That's bad. > > Also, it is impossible for you to write the equivalent of that fold=20 > expression under your syntax. You can write the equivalent of=20 > `std::forward(args) && ...`. But you can't actually do th= e=20 > fold without forwarding. And that may not be what you want. > > That's worse. > > Post-fix operators that can be currently used in fold expressions are a= =20 > non-starter. Prefix operators that can currently be used in fold=20 > expressions are a non-starter. > > --=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/4eb665e1-97fa-4e1a-93e5-e446b5145866%40isocpp.or= g. ------=_Part_36273_776154330.1527573981929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Richard=C2=A0

A keyword wil= l not be a good solution for move, not better enough then the current one. = I care for move as much as forward.

I also feel ke= ywords are dead-end in C++ simply by looking to many if not all newly intro= duced - decltype, nullptr, co_await, constexpr, reflectexpr?=C2=A0
I know the reasons behind all these, but that do not change the fact = I don't like them. =C2=A0

@Nicolas and Nic= ol=C2=A0

You are right, I have been a bit too opti= mistic, but that's normal I guess.
Thanks for pointing this <= i>obvious issue. Guess it was too good to be true/possible.
<= br>
In any case - there are plenty of other options. That was jus= t the best in general. I will throw at you a bunch more by the end of the d= ay.

Thanks again!

On Tuesday, May 29, 201= 8 at 3:32:10 AM UTC+3, Nicol Bolas wrote:


On Monday, May 28, 2018 at 4:20:28 PM U= TC-4, mihailn...@gmail.com wrote:


On Monday, May 28, 2018 at 8:50:41 PM UTC+3, = Ga=C5=A1per A=C5=BEman wrote:
Nicol,

I forsee a fight to distinguish the unary && = from the binary && in fold expressions, but otherwise...
I don't think there=C2=A0is=C2=A0an "otherwise" at that point. If &&... already has a= meaning, that's the end of the conversation. Backwards incompatible ch= anges for this are probably a non-starter.
The "otherwise" was not meant as "I see a possi= bility of changing the meaning of existing syntax" :). I meant that (a= rgs&&)... might actually still be possible. I do think it's iff= y.

What the problem might be?

auto c =3D a&& && b;

template<class... T>
auto sum(T&&am= p;... args) {
=C2=A0return (args&& && ... && T{}= );=C2=A0
}
=C2=A0
These will do what it's expec= ted.

Backwards compatibility is= not about the ability to write correct code now. It's the abili= ty for previously correct code to remain correct.

`args && ...` is a fold expression. What you want will no lo= nger make it so.

That's bad.

Als= o, it is impossible for you to write the equivalent of that fold expression= under your syntax. You can write the equivalent of `std::forward<declty= pe(args)>(args) && ...`. But you can't actually do the = fold without forwarding. And that may not be what you want.

<= /div>
That's worse.

Post-fix operators tha= t can be currently used in fold expressions are a non-starter. Prefix opera= tors that can currently be used in fold expressions are a non-starter.

--
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/4eb665e1-97fa-4e1a-93e5-e446b5145866= %40isocpp.org.
------=_Part_36273_776154330.1527573981929-- ------=_Part_36272_1107401589.1527573981928-- .