220 38233 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Simple, terse universal forwading for the next decade Date: Mon, 28 May 2018 16:53:56 +0200 Lines: 369 Approved: news@gmane.org Message-ID: 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002a1c85056d454aa6" X-Trace: blaine.gmane.org 1527519124 22777 195.159.176.226 (28 May 2018 14:52:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 May 2018 14:52:04 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBEFQWDMAKGQE5MGIMLA@isocpp.org Mon May 28 16:52:00 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 1fNJV8-0005mG-PY for gclcip-std-proposals@m.gmane.org; Mon, 28 May 2018 16:51:59 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id q24-v6sf10831430iob.0 for ; Mon, 28 May 2018 07:54:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527519249; cv=pass; d=google.com; s=arc-20160816; b=scsx8OGlGqOI3GZO0EIX8FBRaY8ZJxrrUUqr/rYIm1kvHhsNXdPIOLc51O/NNKe3a5 P/y0f344v6eSnZrRs/iyBy+ijcI2gidGOHEqJSIkS9LxO7ZyFs/eN+1TJbzIqPeNRBbV pavQRQzE1WXj15Lq0o6pv+1++o0wAMmMg85618NimV/lB5fwz4VrN+D+F+DDy6FQkEYp bGpWN4WsbORRiY32oLfRjq7eczI5H8l1PGkiBDbfAMPLwiCA+chyfB30WbdpQhXS6/0p nT0gfE7nbfhLyv+zzdiefeyH0NHJe60GmGVPbexYtoX3b3Sq9IkZmmqBYv2gBPiKrWe1 i/hg== 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:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=xYMadlFc/Kk0//MvyEO+T7AArnPgorqtl5IUtSeqfo8=; b=kiIxByEoD5aUCIsinQJmgz/SLbozSvlak6C2jJyNKvo/Z0H8RQJv8K/tgeWUnORZsN MpuYIl36ZoplAjSFfCxCKzWUH3TSEcFG0B0dcDk/e0jSv0joys0O1k50JivLLtZxNocR ZC/uO07Hkcnh0GuKJpPzv8SnSuxVo+5XFjhP+Y9TEmsp7WiWezbqYhBkyZ7tEvWqRs84 S5ujIZZ59tplKWxi9c41r6nAzfXqrtT4xZrGPENlu79kPRTn8LhjRKuB0638uw6xqYVj t5WRetycKQzPHphinAyK0yfgxfMwKWlcEvLGvXgwZvrOH9HIRToy1+30TetFoE637jFB fdlA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IpFDHqTf; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@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 :cc: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=xYMadlFc/Kk0//MvyEO+T7AArnPgorqtl5IUtSeqfo8=; b=oRt4OAF+yBqvTTRVMuxB+SQPhWmWw/yw1/SjDWLtpILq8QfJ4WRrrbXBWp9L1Kj++Z /GAsIW21DT50LguplH5GDQ24/KfpCucBe1u9Wlb+TOSbYjx6fgO1Iuk26LH83ar0Qsiv 6SfjC6UDeO+BRjk9bqTsaz2A7toc3qLAo4Nwk97M2/KrCQg1prEs6pbWboXu0Ydo/LRh MEaRroo5UHyhsgpQJ5JsgxXQXXTe58KahTC4GKR3Nyq31yJXvRyGy/iy1J+l4TQ2IxCo LKwyKSi+n03ExmO16oJ5fLN7jrUfFA428pg33h3fWkmgHy16cxIT0rgOiq1xOQHrUrAj EJ9g== 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:cc: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=xYMadlFc/Kk0//MvyEO+T7AArnPgorqtl5IUtSeqfo8=; b=S8jIw9RBxVRjvklspiy3WV1nn/S1kPqfOpq+cSZ0FRwRrs0Mp7FNsoq47SrnZfIEIS oAwvqW1X1kp2fdcHntXDkTkQLDdbklCB8VSJ0ClsEee0Imur8fTcQLQ0lBMZ4NbqWGXE 3O4qedECelizqbasDILVgkB2q1+jVp4zjksgM5cLo/brzUOF8LO1JemSa1Q7PYeYdu11 Fnci/O9gjoaSoA42SoFwMAjOxCoFFk+pKPr+nwxUM1daFgNssGIysBE4BTaurZ+Ax3ID nKLBHhQUeBF0GSLgFzO+oyuTfQDMe5AFQiKjJu5skTAToYh3Os/lAUdlnpg2Jqv/OJdV XmYA== X-Gm-Message-State: ALKqPwc3gktN9hsCZKxcyFuz/9pACG8RmvCHcbzKh7Kx2fTWyV/BVNwW IIv0zWiRmE/Ai6O9nn8b6NEdpw== X-Google-Smtp-Source: ADUXVKLG3s5VjNUifp90a31P33SMb4km/LEB/USoHFwQTxLIYK9mAf9SHJ2N0/9O5ckiOWojg2AgqQ== X-Received: by 2002:a6b:e610:: with SMTP id g16-v6mr6373924ioh.122.1527519249518; Mon, 28 May 2018 07:54:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:784b:: with SMTP id p72-v6ls5616074itc.1.canary-gmail; Mon, 28 May 2018 07:54:08 -0700 (PDT) X-Received: by 2002:a24:a104:: with SMTP id y4-v6mr12011081ite.68.1527519248383; Mon, 28 May 2018 07:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527519248; cv=none; d=google.com; s=arc-20160816; b=GaWtJWWSJ0JEj9AYs6VYDzjO4IHCK56Shf7qsqwOW4ot2IGay2pZ++6aJDhF4r8ys5 +YxVo1vix6x0YzzQQBiVIq4I7CjngJFI1Ie3t5Mra8EapE6ja/fEyM+oNDXtQ6klVwXe MBQF+IWXyUDIrVZxmWrg3fLA3h2E9lyeoSKEqJgRUnnZvLF9fxvV3yu3D7RCn2Qc1RlX 8hvQSE/bFYxOoKQSZNJ1eTk569gMeC40epDFGD00GJrU+nYbyVqxH+KUxi25oNV064Dm fYkZjxlQbnaCL0dqt6la2QEGwkKLRe59IjFqJ1moki50Is8HNWhFmvLbGvOf7MKLoVUr iryg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature:arc-authentication-results; bh=9xuKhVh44i/olZHLFjfxon6rOSyxyNDmIRyUeDvI1zo=; b=BbVFzN8EUqZ1TWC9MEqVaN6XimR2+UNta6PL6lmTdpqR1nTatD1aR61VryeN6pdNnd DOk9Sjf05jfAjEO07Rs7csWtZw1l7zEi/hULjmteALFfU7OBpfH28w9s90pPTp/ccg4R 5uZoDfiakjBkqOBGezhhlbKkX4VqJw8VZM+j75fCIQ98p/+Ntl++vyJ1NVFx9UlTbDal kfYV7EQjEg+K+suByPqLToVPZoo5mOey3Bt6wvRb9ULDCwXpOqndwk+7XGBcEuqPQwMr gCdR2unsbb34s0zC4NeXhDWcv+5i/t0EP6vmza8gZcC7sTgQ0FBw1+P925CG10cYCLpB 6EGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IpFDHqTf; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@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 i131-v6sor2645927iof.119.2018.05.28.07.54.08 for (Google Transport Security); Mon, 28 May 2018 07:54:08 -0700 (PDT) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a6b:5110:: with SMTP id f16-v6mr11061041iob.118.1527519247995; Mon, 28 May 2018 07:54:07 -0700 (PDT) In-Reply-To: X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IpFDHqTf; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@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:38233 Archived-At: --0000000000002a1c85056d454aa6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > *Motivation to merge forward and move (not in order):* I think it's clear that the committee is already in agreement with you. The only objections previously seemed to be that an operator was proposed. For the record, I also agree with you. A language should allow a programmer to express intent succinctly. give() would help c++ with that. On Mon, 28 May 2018 at 13:56, Ga=C5=A1per A=C5=BEman wrote: > And one last thing >> One way to look at it is - *it is just a form of overloaded operator*, >> and overloaded operators are a cornerstone of C++ >> It has two "overloads" >> - for forwarding reference - In that case it will expand to forward (or >> static_cast or whatever) >> - for everything else - In that case it will expand to move (or >> static_cast&&> or whatever) >> Such an operator (or overload) is not possible today, so we need compile= r >> support. > > > It is *not* a form of an overloaded operator - the operator is always > invoked on an lvalue, and whether it's a forwarding reference depends not > on its type, but on *whether the value-category was deduced in the > current context*. We have absolutely no precedent for this. You need a > different abstraction. > > I'd love to see a `forward` operator that would let me omit the > (foo). I see your point wrt. move and forward being the > same, because in either case, you can't use the value afterwards (because > you must always program to the more restrictive contract, which in case o= f > forward means the move part). *give* makes sense, ish. But, please don't > confuse it for an operator. It's a context-sensitive thing of a category = we > just haven't ever had. > > G > > > On Mon, May 28, 2018 at 8:27 AM, wrote: > >> >> >> On Sunday, May 27, 2018 at 11:39:01 PM UTC+3, Nicol Bolas wrote: >>> >>> On Sunday, May 27, 2018 at 3:05:10 PM UTC-4, mihailn...@gmail.com wrote= : >>>> >>>> So the question still stands: >>>> >>>> Is there a *valid* reason to move a forwarding reference? Is there a >>>> *need* for this? >>>> >>> If there is a need, then move can be preserved and used instead. >>>> If there is no need, move *could* be deprecated. >>>> >>>> Question 2: Should one ever use forward *instead of* move? >>>> >>>> Question 3: Will give ever result in ambiguity in code? As in human >>>> confusion or uncertainty of what is happening? >>>> >>>> Question 4. Is it possible to implement? >>>> >>>> I believe the answers of these 4 questions make the said proposal a >>>> good improvement to the language. >>>> >>> >>> I believe these questions are backwards. Your questions are about >>> validating the proposal, not *motivating* it. Basically, you're asking >>> "why not" rather than "why". >>> >>> "Why" is the question your proposal needs to answer. >>> >> >> >> Let me answer this. >> >> *Motivation to merge forward and move (not in order):* >> >> 1. Less of the "C++ is experts only". >> Removing the distinction (*on a practical, hands down level)* will make >> the language more friendly do beginners. >> The distinction is subtle and not initially clear, where if merged, when >> the user sees && on a type, he will know, he needs to use the matching >> operator. >> Always. Always the same! >> >> 2. Better code. >> Eliminating the possibility to get it wrong - to use one in the place of >> the other will make for less bugs, easier maintenance, easier refactor. >> >> 3. The compiler should do the job for us. >> If there are *no decisions* to be made on the part of the programmer, he >> is not really coding logic, not really "programming" - only truckling to >> the language. >> >> 4. Merger will make it way, way easier to came up with operator. >> Both move and forward should be an operator, not just because verbosity, >> but because they are integral part of the language, not a library add-on >> and a wildly used (may be not even enough). >> A language which has an operator to take the address of a variable, but >> can not naturally express the notion of passing the said variable along, >> definitely shows its age. >> >> (5.) It is actually good design. >> Lets consider an orthogonal example. >> One has two classes Image and File. Then the image has freeImageData() >> method, the file has closeFileHandle() and the user is forced to spell o= ut >> each one for each object. >> The sooner or later someone will come up with solution which trades the >> explicitly of the methods for some base notion of finishing up with the >> object. >> Someone will invent some release() method. >> >> Here the things are similar - different preconditions, different actions= , >> but same base notion - passing along. >> >> And one last thing >> >> One way to look at it is - *it is just a form of overloaded operator*, >> and overloaded operators are a cornerstone of C++ >> It has two "overloads" >> - for forwarding reference - In that case it will expand to forward (or >> static_cast or whatever) >> - for everything else - In that case it will expand to move (or >> static_cast&&> or whatever) >> >> Such an operator (or overload) is not possible today, so we need compile= r >> support. >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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/609892ba-f7= 17-4458-b9e3-c5975378ad29%40isocpp.org >> >> . >> > > -- > 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/CAANG%3DkUqV= _OU%2BXTZpgMg3LJo_EH1P9CMWVXi%2BZUx4aa-mcH54g%40mail.gmail.com > > . > --=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/CALvx3haxYiRPejcW3TqvCWcD9RRm%2BqZcz2F6vcVMVBx3P= DJF2w%40mail.gmail.com. --0000000000002a1c85056d454aa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Motivation to merge=C2=A0forward=C2=A0and=C2=A0move=C2=A0(not in order):

I think it's clear that the committee is alread= y in agreement with you. The only objections previously seemed to be that a= n operator was proposed.

For the record, I also ag= ree with you. A language should allow a programmer to express intent succin= ctly. give() would help c++ with= that.

On Mon, 2= 8 May 2018 at 13:56, Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.com> wrote:
<= /blockquote>
In that= case it will expand to move (or static_cast<remove_reference_t<T>= &&> or whatever)
Such an operator (or overload) is not= possible today, so we need compiler support.=C2=A0

It is not=C2=A0a form of an overloaded operator - the opera= tor is always invoked on an lvalue, and whether it's a forwarding refer= ence depends not on its type, but on whether the value-category was dedu= ced in the current context. We have absolutely no precedent for this. Y= ou need a different abstraction.

I'd love to s= ee a `forward` operator that would let me omit the <decltype(foo)>(fo= o). I see your point wrt. move and forward being the same, because in eithe= r case, you can't use the value afterwards (because you must always pro= gram to the more restrictive contract, which in case of forward means the m= ove part). give=C2=A0makes sense, ish. But, please don't confuse= it for an operator. It's a context-sensitive thing of a category we ju= st haven't ever had.

G

=

On Mon, May 28, 2018 at 8:27 AM, <mihailnajdenov@gmail.com&g= t; wrote:
<= br>
On Sunday, May 27, 2018 at 11:39:01 PM UTC+3, Nicol Bolas wrote:
On Sunday, May 27, 201= 8 at 3:05:10 PM UTC-4, mihailn...@gmail.com wrote:
So the question still stands:<= /div>

Is there a valid reason to move a forwardin= g reference? Is there a need for this?
If there is a need= , then move can be preserved and used instead.
If there is no nee= d, move could be deprecated.

Question 2: Sh= ould one ever use forward instead of move?

= Question 3: Will give ever resu= lt in ambiguity in code? As in human confusion or uncertainty of what is ha= ppening?

Question 4. Is it possible to implement?<= br>

I believe the answers of these 4 questions mak= e the said proposal a good improvement to the language.

I believe these questions are backwards. Your ques= tions are about validating the proposal, not motivating it. Basicall= y, you're asking "why not" rather than "why".
=

"Why" is the question your proposal needs to = answer.


Let me answer this.

Motivation to merge forward and move (not in order):

<= /div>
=C2=A01. Less of the "C++ is experts only".=C2=A0
=
Removing the distinction (on a practical, hands down level) wil= l make the language more friendly do beginners.=C2=A0
The distinc= tion is subtle and not initially clear, where if merged, when the user sees= && on a type, he will = know, he needs to use the matching operator.
Always. Always the s= ame!

=C2=A02. Better code.=C2=A0
Eli= minating the possibility to get it wrong - to use one in the place of the o= ther will make for less bugs, easier maintenance, easier refactor.

=C2=A03. The compiler should do the job for us.=C2=A0
If there are no decisions to be made on the part of the progra= mmer, he is not really coding logic, not really "programming" - o= nly truckling to the language.=C2=A0

=C2=A04. Merg= er will make it way, way easier to came up with operator.
Both move and forward should be an operator, not just because verbosi= ty, but because they are integral part of the language, not a library add-o= n and a wildly used (may be not even enough).
A language which ha= s an operator to take the address of a variable, but can not naturally expr= ess the notion of passing the said variable along, definitely shows its age= ..

(5.) It is actually good design.
Lets = consider an orthogonal example.=C2=A0
One has two classes Image a= nd File. Then the image has freeImageData() method, the file has closeFileH= andle() and the user is forced to spell out each one for each object.
=
The sooner or later someone will come up with solution which trades th= e explicitly of the methods for some base notion of finishing up with the o= bject.=C2=A0
Someone will invent some release() method.

Here the things are similar - different preconditions, diff= erent actions, but same base notion - passing along.

And one last thing

One way to look at it is - <= i>it is just a form of overloaded operator, and overloaded operators ar= e a cornerstone of C++
It has two "overloads"=C2=A0
=C2=A0- for forwarding reference - In that case it will expand to fo= rward (or static_cast<T&&> or whatever)
=C2=A0- for= everything else -=C2=A0In that case it will expand to move (or static_cast<remove_= reference_t<T>&&> or whatever)

=
Such an operator (or overload) is not possible today, so we need compi= ler support.=C2=A0

--
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-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/609892ba-f717-= 4458-b9e3-c5975378ad29%40isocpp.org.

--
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-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/CAANG%3DkUqV_OU%2BXTZpgMg3LJo_EH1P9CMWVXi%2BZUx4aa-mcH54g%40mail= ..gmail.com.

--
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/CALvx3haxYiRPej= cW3TqvCWcD9RRm%2BqZcz2F6vcVMVBx3PDJF2w%40mail.gmail.com.
--0000000000002a1c85056d454aa6-- .