220 38387 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: Thu, 31 May 2018 01:08:40 -0700 (PDT) Lines: 212 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> <4d68237c-077a-4408-abf1-5f9670311f71@isocpp.org> <70fe7dc7-b8a6-4498-9aa6-f88e6af06506@isocpp.org> <0c4f8aa4-6b4f-4fe3-a02a-ef33eae990a8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2670_1390436513.1527754120581" X-Trace: blaine.gmane.org 1527754001 28603 195.159.176.226 (31 May 2018 08:06:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 08:06:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBCO3X3MAKGQEI7U5EUY@isocpp.org Thu May 31 10:06:37 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOIbU-0007H7-4U for gclcip-std-proposals@m.gmane.org; Thu, 31 May 2018 10:06:36 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id w7-v6sf6954887ywf.1 for ; Thu, 31 May 2018 01:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=UGDdbyxcCA2Hows1TSxRLDEdFfHXhdxWND19NJnOK3k=; b=fJ/uOnIJ1/pk5ADdOtsRLStZFFHYdtlRYLCSKi7YIietRDgcHdAzJ/PjhJV9TnwRlF IRlLt1qxEtPOoGFKa6BOVOvnfDFiXVCfBlkMrvGXFqsNo1/V+2tEsrv0XXt+xe01EvMe h0Rxbr/m50ZcDbMxfZY96JEOfiK9EZFnX3OTKWVHfOg3rAOeLiUA4aQ/JRhTkKvzv9CP apTICPq7OOY7Kl9SVEKv4Yj2aovUNmQYnCB+a6uIgdZdWRWgaDMVfaCi3ydp136+H+UT DrLpU1DHI8cBD+ghAC/2IPsa5RDODpWjslkUtcC6MF6+SYWQbK/PDll+1QEM05/S+Nsd 9l0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=UGDdbyxcCA2Hows1TSxRLDEdFfHXhdxWND19NJnOK3k=; b=EFvwdftodquvrO4r6FllFCF7gUp3oBzT6cviH1NagHUPPcv3uG0FcaSKWGBHrNsC3/ vQXEue5cyTOCkmSpeuJ5SU+NvGVdQdcGeieyX5h7CJfdaar7N5WvpzBD6Hy83xVbt66F nxiW8oB3BpQoTAlUWIpETK1X/x5rPZyXJEaz5zSOp0GnQoCmIoJjkgELLn8EkcC+8tBU 0E+YFjEXtdXqLZhDaPeZUje7T8POTAkLZ1dS3BJZJv2xat+4bZBw2uFK7JV8XP8yNLJi Haq2DGBRobFaBH4xxN0FvCYZtLnooozohamo1AL0J611uoeDz3tYyEW1eQFJ1IPMUxMJ wNsg== 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: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=UGDdbyxcCA2Hows1TSxRLDEdFfHXhdxWND19NJnOK3k=; b=kOx1JSNtcwVPEsws7wc5+JbWeId8aH0voRMBah3DaAbpUeEhOq73sFHSVYJqn20mYS /YBn60ugdqSoSirr/rygNV5iymu/J9/7DhTvr3ub4KjOqs4JERgnKPc7BAEwbdK1xCI6 XfqmhoFSkmgtH0BZZgrR0SLGr1aUx3WBKkEO1POAT+VkmIXy98NTQ7TJFFVCBJ6No89s MHyEgPP577m+LfFzaJAP6otPoa+X4kZH2iKzwuZH6DkRK6jYHhDWwim20PUhIg99uQJF RamUzH48WICVA7tdxRGNxbIzZcwK5Ty/VvSe6NVxIVNaMaeUQEtvXeGMoWqAJPIyj2Yl xhhw== X-Gm-Message-State: ALKqPwcuI3H8DoSfZGs2OUxs3sGOqhMdB10dE2QpJvB69Z450GkGMoq8 mH5gAacKUH0SlQQnNC+zlYOaxg== X-Google-Smtp-Source: ADUXVKI6YQfB9fplADoH8Yby3UjMZskjNmcQy/CALd8dmjYfhr9HW9ZhtNtSgg1o6biwJ/8p30DgiQ== X-Received: by 2002:a0d:c787:: with SMTP id j129-v6mr486926ywd.11.1527754122000; Thu, 31 May 2018 01:08:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:9e56:: with SMTP id v83-v6ls2826605ywg.38.gmail; Thu, 31 May 2018 01:08:41 -0700 (PDT) X-Received: by 2002:a81:9a4f:: with SMTP id r76-v6mr218098ywg.0.1527754121068; Thu, 31 May 2018 01:08:41 -0700 (PDT) In-Reply-To: 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:38387 Archived-At: ------=_Part_2670_1390436513.1527754120581 Content-Type: multipart/alternative; boundary="----=_Part_2671_842014962.1527754120581" ------=_Part_2671_842014962.1527754120581 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, May 29, 2018 at 1:23:07 AM UTC+3, Richard Hodges wrote: > > Anyone proposing adding another operator to c++ has clearly not recently= =20 > had to teach the language or maintain code. > > forward (or give, or similar) should be a keyword. I know the committee= =20 > fears adding keywords, but this fear is unfounded. The constant=20 > hoop-jumping merely to avoid the inevitable simply creates technical debt= =20 > which will impede design choices in the future. > Ok, so I decided to play around with the a possible keyword. Here's what I= =20 came up with. giveop giveup givein giveof giveovr - . - passon passop passin passof passovr - . - handin handovr These are self-explanatory.=20 - . - Two unorthodox variants func givn (args givn=E2=80=A6) or func taken (args taken...) As you can see, as postfix. And BTW, purely from language standpoint other keywords can work as postfix= =20 as giveovr, handin etc - . - remit Odd, but short and probably not taken. "refer (a matter for decision) to=20 some authority." - . - letgo - . - convey Self-explanatory and should be usable as-is.=20 There is also the category of words, stressing on the fact variable is no= =20 longer used in the current context. vacate - . - evict - . - layof Granted, these are less suited for forward and more for move. Still, the=20 benefit is the strong do-not-use waring. IMO pass "wins" as it fits perfectly with forward - argument passing AND=20 fixes an annoying confusions with move, were=20 a) one can move const objects. b) move-might-not-move=20 If you use pass, visually you are not laying by saying you are moving - you= =20 just pass the object ant trust, the compiler it will transfer it the best= =20 way. Needless to say, I still believe an operator is the better option (see=20 pre-previous post), exactly because we don't have come up with a name! Comments are welcome. =20 --=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/e7ee5875-c667-488a-80d3-e896ff8af163%40isocpp.or= g. ------=_Part_2671_842014962.1527754120581 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, May 29, 2018 at 1:23:07 AM UTC+3, Rich= ard Hodges wrote:
Anyone proposing adding another operator to c++ has clearly not recentl= y had to teach the language or maintain code.

forward (or give, or similar) should be a keyword. I know the committee fe= ars adding keywords, but this fear is unfounded. The constant hoop-jumping = merely to avoid the inevitable simply creates technical debt which will imp= ede design choices in the future.


Ok, so I decided to play around with the a possible keyword. Her= e's what I came up with.

giveop
giveu= p
givein
giveof
giveovr

- . = -

passon
passop
passin
passo= f
passovr

- . -
<= font face=3D"courier new,monospace">
handin
handovr

These are self-explanatory.=C2=A0

- . -

Two unor= thodox variants

func givn (args givn=E2=80=A6)
or
func taken (args taken...)

As you can see, as postfix.
And BTW, purely from language standpoint other keywords can work as post= fix as giveovr, handin etc

- . -

remi= t

Odd, but short and probably not taken. "refer (a matter for decisio= n) to some authority."

- . -
=
letgo

- . -

con= vey

=
Self-explanatory and should be usable as-is.

There is a= lso the category of words, stressing on the fact variable is no longer used= in the current context.

vacate
=

- . -

evic= t

- . -

layof

Granted, these are less suited for forward and more for m= ove. Still, the benefit is the strong do-not-use waring.

IMO = pass "wins" as it fit= s perfectly with forward - argument passing AND fixes an annoying confusion= s with move, were
=C2=A0a) one can move const objects.
=C2=A0b) move= -might-not-move=C2=A0

If you use pass, visually yo= u are not laying by saying you are moving - you just pass the object ant tr= ust, the compiler it will transfer it the best way.

Needless = to say, I still believe an operator is the better option (see pre-previous = post), exactly because we don't have come up with a name!
Comments are welcome. =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-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/e7ee5875-c667-488a-80d3-e896ff8af163= %40isocpp.org.
------=_Part_2671_842014962.1527754120581-- ------=_Part_2670_1390436513.1527754120581-- .