220 38386 <45954c2a-d722-4f42-b491-564b07f7fd77@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: Thu, 31 May 2018 01:05:12 -0700 (PDT) Lines: 1028 Approved: news@gmane.org Message-ID: <45954c2a-d722-4f42-b491-564b07f7fd77@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2686_317291908.1527753912339" X-Trace: blaine.gmane.org 1527753788 13996 195.159.176.226 (31 May 2018 08:03:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 08:03:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBOOZX3MAKGQEPEDPKJY@isocpp.org Thu May 31 10:03:04 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOIY3-0003XQ-Ff for gclcip-std-proposals@m.gmane.org; Thu, 31 May 2018 10:03:03 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id j11-v6sf14002086ywi.6 for ; Thu, 31 May 2018 01:05:14 -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=Vz6typCp4UG/7hjFhGs45B6CUTTbtxQMv3x+rf2yFDQ=; b=WNACxxw7pF1qcl6P8rvIDFO5eN9gvofUsd8x4sY3zaEFD/ql75N6Oeo3Otcv1dDZ82 7OQ6apmH99F3bV3guhev/R0adsWCa8l3EeK2oflgIArccMqgaiF+vpq0xeLUnWa19DYQ kb3H/2HSeJowfg5IOyZdzM7lDTsI2+RKplH5EHyjQpahXVJ00RdtEZmDYgHIGSoOZnri HZudiSok+21TXI8AJ1u14Eno2acpUhfsitA0tosk7RgKrcMNx7CBGIJyOMEDz6Mcoc8t LgYrmuYexrWbxdm+E6LyC6BnhHV6M+/vWpGUOLIKIOMpk9CxKsM2GE1Bu+HGlL+yI3ep UVcg== 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=Vz6typCp4UG/7hjFhGs45B6CUTTbtxQMv3x+rf2yFDQ=; b=ldvL2IGEyqsdq3LRa/9WzUvR7WuNlt1E5rzdrIv5vR5CtR43oKKQRhONrGLPvK2Th+ iZLfD06WEmCUVGTmXIx955+9kGjNO8gSIIrWtvubsLMr1CZP2pxgUDS6r0Jkcw2Vg71G HC5FfuB4xntIGHd6hM82bIUV5VE1YTTXs+O2/Kv+Sm99ylwBslrKWD0Sr5Vv1gi+l9o9 CDEqjDlAUrihpP8Pt0ck1SwXLyYTy5K6qryh6aKQuQzFmh/hQI5e2vUlBbAdCD7xAKBk loIVUUAP9b3lqfD8qGUfmbw89gFGX2Ka/cB71yMzRQTAZzOxal/XIsn/FHmZs/1QOuDV iXMQ== 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=Vz6typCp4UG/7hjFhGs45B6CUTTbtxQMv3x+rf2yFDQ=; b=iyjrQGh7al2PlMEEIYSTeb57yYKVHbMXt/UlQR3z1jdjNpTReT0DP5YIRlqYMGA78G YJOJ4J7fg6dk+hBsVaTbr6rTE8tyqNHOgxyPrGGFVbrrA2wz1mPDYr2muru++RGokPRp s0f6SdXKtw69FSd+KS7s5fNBMmMWeb5wMFGfaBsWlLMunZdrqJZhnv4WbhCvdZ/WyOOT lmB4BD1iVp2M75sMilW9BgIyizvg3yqYLnbClSubGAVCEwsnSoF8Cqld9LJL16mVPo0V LvndIdzyPDUs8dCrTOKE++TOSVFgCNVaNczXKPm8CJMdUD3G8iEo+23D8MgwMt09nwb7 FL3g== X-Gm-Message-State: ALKqPwfiqwTHaadrwc3825LFhg7Jl0dxr4kQtgi2SWFToRiPgL5BZG15 YRpRUkMTP/5T3wCcIyie8hut2w== X-Google-Smtp-Source: ADUXVKL0OxTTgb4fVunFbBokOuiy5ITXSOWv0bjEb7AUkmvRNVtfcFmTtExwbE+tE8awJT7dmsKeJw== X-Received: by 2002:a81:c84:: with SMTP id 126-v6mr180343ywm.103.1527753914257; Thu, 31 May 2018 01:05:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:2089:: with SMTP id g131-v6ls4225236ywg.34.gmail; Thu, 31 May 2018 01:05:13 -0700 (PDT) X-Received: by 2002:a81:4b49:: with SMTP id y70-v6mr215480ywa.1.1527753913081; Thu, 31 May 2018 01:05:13 -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:38386 Archived-At: ------=_Part_2686_317291908.1527753912339 Content-Type: multipart/alternative; boundary="----=_Part_2687_976217084.1527753912341" ------=_Part_2687_976217084.1527753912341 Content-Type: text/plain; charset="UTF-8" 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 > had to teach the language or maintain code. > > forward (or give, or similar) should be a keyword. I know the committee > fears adding keywords, but this fear is unfounded. The constant > hoop-jumping merely to avoid the inevitable simply creates technical debt > which will impede design choices in the future. > > Ok, so I decided to play around with the a possible keyword. Here's what I came up with. giveop giveup givein giveof giveovr - . - passon passop passin passof passovr - . - handin handovr These are self-explanatory. - . - Two unorthodox variants func givn (args givn...) or func taken (args taken...) As you can see, as postfix. And BTW, purely from language standpoint other keywords can work as postfix as giveovr, handin etc - . - remit Odd, but short and probably not taken. "refer (a matter for decision) to some authority." - . - letgo - . - convey Self-explanatory and should be usable as-is. There is also the category of words, stressing on the fact variable is no longer used in the current context. vacate - . - evict - . - layof Granted, these are less suited for forward and more for move. Still, the benefit is the strong do-not-use waring. IMO pass "wins" as it fits perfectly with forward - *argument passing *AND fixes an annoying confusions with move, were * a)* one can move const objects. *b) *move-might-not-move If you use pass, visually you are not laying by saying you are moving - you just pass the object ant trust, 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 (among other things)! Comments are welcome. Thank You. -- 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/45954c2a-d722-4f42-b491-564b07f7fd77%40isocpp.org. ------=_Part_2687_976217084.1527753912341 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 keywo= rd. Here's what I came up with.

giveop
giveup
givein
giveof
giveovr

- . -

<= /span>
passon
<= div style=3D"background-color: transparent; border-bottom-color: rgb(34, 34= , 34); border-bottom-style: none; border-bottom-width: 0px; border-image-ou= tset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-ima= ge-source: none; border-image-width: 1; border-left-color: rgb(34, 34, 34);= border-left-style: none; border-left-width: 0px; border-right-color: rgb(3= 4, 34, 34); border-right-style: none; border-right-width: 0px; border-top-c= olor: rgb(34, 34, 34); border-top-style: none; border-top-width: 0px; color= : rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helveti= ca&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant:= normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; marg= in-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-botto= m: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align= : left; text-decoration: none; text-indent: 0px; text-transform: none; -web= kit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">passop
passin
= passof
passovr
<= b>
- . -

handin<= /span>
handovr

These are self-explanatory.=C2=A0

- . -
<= /strike>
Two unorthodo= x variants
func givn (args givn...)
or
fun= c taken (args taken...)

As you can see, as = postfix.

And BTW, purely from language standpoint = other keywords can work as postfix as = giveovr, handin etc=
<= /sub>
- . -
<= div>
remit

Odd, but = short and probably not taken. "refer= (a matter for decision) to some authority."
<= font face=3D"arial,sans-serif">
- . -<= /div>
=
let= go

- . -

convey

Self-e= xplanatory and should be usable as-is.=C2=A0


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

vacate

- . -

evict

- . -

=
layof

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

IMO pass "wins" as it fits perf= ectly with forward - argument passing AND fixes an annoying confusio= ns with move, were=C2=A0
<= b>=C2=A0a) one can move const objects.
=C2=A0b) move-might-not-move=C2=A0

If you use pass, visual= ly you are not laying by saying you are moving - you just pass the object a= nt trust, the compiler it will transfer it the best way.


Need= less to say, I still believe an operator is the better option (see pre-prev= ious post), exactly because we don't have come up with a name (among ot= her things)!


Comments are welcome. Thank You.
=

--
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/45954c2a-d722-4f42-b491-564b07f7fd77= %40isocpp.org.
------=_Part_2687_976217084.1527753912341-- ------=_Part_2686_317291908.1527753912339-- .