220 25214 <7ca90cde-f8d6-435b-97c1-5474490d1001@isocpp.org> article Path: news.gmane.org!not-for-mail From: Omer Rosler Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Post-fix operator declaration change. Date: Tue, 15 Mar 2016 06:29:50 -0700 (PDT) Lines: 258 Approved: news@gmane.org Message-ID: <7ca90cde-f8d6-435b-97c1-5474490d1001@isocpp.org> References: <22101a9e-0e9a-4e70-b332-a1cd9ced7eb6@isocpp.org> <8e0337ea-ec51-464e-b45d-06d1b4a91839@isocpp.org> <69e71162-a69d-41a8-b48c-d6eef8a46208@isocpp.org> <78c5c7c6-2a1c-4dac-aabd-916685cfc48a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_94_456540400.1458048590978" X-Trace: ger.gmane.org 1458048597 9815 80.91.229.3 (15 Mar 2016 13:29:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Mar 2016 13:29:57 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC2L3NWCRYJBBT44UC3QKGQEI5LJ6ZA@isocpp.org Tue Mar 15 14:29:56 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1afp2o-0003qB-F1 for gclcip-std-proposals@m.gmane.org; Tue, 15 Mar 2016 14:29:54 +0100 Original-Received: by mail-yw0-f198.google.com with SMTP id n3sf28237710ywd.3 for ; Tue, 15 Mar 2016 06:29:54 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SLj+R+QG/OBGm/FLZ+Pn9oTuwcrpnLP8yN/PwWmpLeA=; b=j8bFV9gqySyAtCgeYeqwR2w5quDSG3p90biXkB95NTOOAVAkmz2lMt3clJ4sxQ3s8w Khg3J0XEh5qzqceA22nycKYIHO2myCSfF42UuoHovP+lbHR3ocKalxyu3ymNNzk7lF54 SwAlS3flWwjNuWxjrZFvcZIBFEvOIaQ4MuMF6CXc14whjNSaT60HEbaLq5rCMScpqLSZ e9BDJ0fQuq3Ub3/X4H83PcZpQm9Aj1z5/kO+8DydauNubRZT1zzlX9esi2+9fxSkVe43 RYaNlCuWPugYcjlhwsgnx3xr+S6YzE7eMenfJV6BErHTf69LiOVnlEOy0XVvOCZPOUVA rk8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=SLj+R+QG/OBGm/FLZ+Pn9oTuwcrpnLP8yN/PwWmpLeA=; b=poEF5jzrqcKDNTla+O/QWD8sYXeZB0B/VIMwMKikERfcMj2/th2DDTYWYTSRJy06FE joCc1N3Kf9T4HUjGL+b8HhSj0qk4ZAbyx8JxNYkM4SDtVmXsgb4SI4l5Upn+Temul8ie an78dADEfK+heBdHTGGfvSkiIRl+Yw6NAwXvyNKUzRsqjzD5GMGui+r8/4kUOv3WeDLs RfgpRk8sUFwGLU395B9z8L8Gb87W9ET6lEK6039c9W0B2e1ANOhZ7+mfEbcIpM8EaM++ nqwB8xFvxhsWeYXia9zyh9cZ+o5PznOl33E1cBCS4EeTUtVlKx3RuVJ8WAXDw27JOsPa PZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=SLj+R+QG/OBGm/FLZ+Pn9oTuwcrpnLP8yN/PwWmpLeA=; b=DDVxb1l2Ip7WjsyUA+hfyZ2op4dB8t1PdPykRgPvVREMMhfEKdzIuAs1Z6B05+2dOv oPlALaY4KXgcZXXDlFwILedbx6g9PeI/P4K3bic35WRm0/IgdRNx/aWI+cg0WM48MKOZ y2HFVANGfxNBSg3Wu41F3KrRIrASAx08qdjZhFytI/FuhToYZd3pZHHDzQFNKcFBCBbZ h6M2BRihX67Gqe9/wLweQok9e/cIcUhPiAjRjjN/BCnUmGj2iiqEe9/d10q8UsUauNKI 0ahQtB0VaA4vI2dRMsqVn2dgWujjusuy+Fe26sTD4oamYVL4feLXA0EXnv3rCdzXzbqj e9DQ== X-Gm-Message-State: AD7BkJIUrvgKG1m75bDaXMVJEFbQoNucqL63pTR3Brzw8XCeStbCQicAH2Tdxt8tZ40FKg== X-Received: by 10.129.157.71 with SMTP id u68mr22017309ywg.47.1458048593532; Tue, 15 Mar 2016 06:29:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.29.5 with SMTP id f5ls1217247igh.30.canary; Tue, 15 Mar 2016 06:29:51 -0700 (PDT) X-Received: by 10.50.103.68 with SMTP id fu4mr390626igb.9.1458048591579; Tue, 15 Mar 2016 06:29:51 -0700 (PDT) In-Reply-To: X-Original-Sender: omer.rosler@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:25214 Archived-At: ------=_Part_94_456540400.1458048590978 Content-Type: multipart/alternative; boundary="----=_Part_95_676631806.1458048590978" ------=_Part_95_676631806.1458048590978 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for the late response, Those aliases look more like a patch than an actual solution. As I see it, it's a problem of the core the language so a language solution= =20 is more appropriate (but maybe that's just me). With a different grammer there is a clear path to eradicate this oddity=20 from new code and maybe with tools, as suggested upthread, from existing=20 code (and maybe even deprecation and removal, but that would be many years= =20 from now). On Thursday, March 10, 2016 at 2:36:24 AM UTC+2, Richard Smith wrote: > > On Wed, Mar 9, 2016 at 3:35 PM, Omer Rosler > wrote:=20 > > Hi, I just came across this old thread and thought why not simply add= =20 > > `prefix` and `postfix` as contextual keywords, such that the following= =20 > > declarations are equivalent:=20 > > X T::operator++();=20 > > X T::operator++() prefix;=20 > > //and=20 > > X T::operator++(int);=20 > > X T::operator++() postfix;=20 > >=20 > > (same with `--` and non-member versions)=20 > >=20 > > This has both backward compatability and clear intent.=20 > > If those keywords would be a part of the operator signature in some way= ,=20 > > there is no ambiguity between the pre/post versions.=20 > > Any thoughts?=20 > > From upthread:=20 > > using prefix =3D void;=20 > using postfix =3D int;=20 > > X T::operator++(prefix);=20 > X T::operator++(postfix);=20 > > ... works with existing compilers today.=20 > > > On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:=20 > >>=20 > >>=20 > >>=20 > >> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas =20 > > >> wrote:=20 > >>>=20 > >>> Additionally, in the grand scheme of things I expect a C++ developer= =20 > to=20 > >>> be able to switch from one standard to another, from a legacy project= =20 > to the=20 > >>> newest green fields task with the newest (even experimental) compiler= ..=20 > If=20 > >>> the concern is that the old construct is *hard*, the alternative is= =20 > having=20 > >>> to learn the same *hard* construct and a different one that might be= =20 > >>> simpler. This is not _overall_ simplifying the language but making i= t=20 > more=20 > >>> complex. If this was adopted, I would have to expect my developers t= o=20 > >>> understand 'operator++(int)' and whatever form fo=20 > 'operator++(postfix)',=20 > >>> together with the understanding that they have to be mutually=20 > exclusive.=20 > >>>=20 > >>=20 > >> We can, eventually, stop learning old constructs. ie The 'register'= =20 > >> keyword and the old version of 'auto'. Maybe some day we will=20 > deprecate=20 > >> typedef. It just takes a long long time.=20 > >>=20 > >> The question is just when is it worth it. Probably isn't worth it in= =20 > this=20 > >> case.=20 > >>=20 > >>=20 > > --=20 > > You received this message because you are subscribed to the Google=20 > Groups=20 > > "ISO C++ Standard - Future Proposals" group.=20 > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an=20 > > email to std-proposal...@isocpp.org .=20 > > To post to this group, send email to std-pr...@isocpp.org = ..=20 > > > To view this discussion on the web visit=20 > >=20 > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f28acaca-099= 4-4f91-b0d6-2fef5635ca70%40isocpp.org.=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/7ca90cde-f8d6-435b-97c1-5474490d1001%40isocpp.or= g. ------=_Part_95_676631806.1458048590978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the late response,
Those aliases look more l= ike a patch than an actual solution.
As I see it, it's a prob= lem of the core the language so a language solution is more appropriate (bu= t maybe that's just me).
With a different grammer there is a = clear path to eradicate this oddity from new code and maybe with tools, as = suggested upthread, from existing code (and maybe even deprecation and remo= val, but that would be many years from now).


On Thursday,= March 10, 2016 at 2:36:24 AM UTC+2, Richard Smith wrote:
On Wed, Mar 9, 2016 at 3:35 PM, Omer Rosler <= ;omer= .....@gmail.com> wrote:
> Hi, I just came across this old thread and thought why not simply = add
> `prefix` and `postfix` as contextual keywords, such that the follo= wing
> declarations are equivalent:
> X T::operator++();
> X T::operator++() prefix;
> //and
> X T::operator++(int);
> X T::operator++() postfix;
>
> (same with `--` and non-member versions)
>
> This has both backward compatability and clear intent.
> If those keywords would be a part of the operator signature in som= e way,
> there is no ambiguity between the pre/post versions.
> Any thoughts?

From upthread:

=C2=A0 using prefix =3D void;
=C2=A0 using postfix =3D int;

=C2=A0 X T::operator++(prefix);
=C2=A0 X T::operator++(postfix);

... works with existing compilers today.

> On Wednesday, March 18, 2015 at 12:18:30 AM UTC+2, Tony V E wrote:
>>
>>
>>
>> On Tue, Mar 17, 2015 at 9:03 AM, David Rodr=C3=ADguez Ibeas &l= t;dib...@ieee.org>
>> wrote:
>>>
>>> Additionally, in the grand scheme of things I expect a C++= developer to
>>> be able to switch from one standard to another, from a leg= acy project to the
>>> newest green fields task with the newest (even experimenta= l) compiler. =C2=A0If
>>> the concern is that the old construct is *hard*, the alter= native is having
>>> to learn the same *hard* construct and a different one tha= t might be
>>> simpler. =C2=A0This is not _overall_ simplifying the langu= age but making it more
>>> complex. =C2=A0If this was adopted, I would have to expect= my developers to
>>> understand 'operator++(int)' and whatever form fo = 'operator++(postfix)',
>>> together with the understanding that they have to be mutua= lly exclusive.
>>>
>>
>> We can, eventually, stop learning old constructs. =C2=A0ie The= 'register'
>> keyword and the old version of 'auto'. =C2=A0Maybe som= e day we will deprecate
>> typedef. =C2=A0It just takes a long long time.
>>
>> The question is just when is it worth it. =C2=A0Probably isn&#= 39;t worth it in this
>> case.
>>
>>
> --
> 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-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocp= p.org/d/msgid/std-proposals/f28acaca-0994-4f91-b0d6-2fef5635ca70%= 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-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/7ca90cde-f8d6-435b-97c1-5474490d1001= %40isocpp.org.
------=_Part_95_676631806.1458048590978-- ------=_Part_94_456540400.1458048590978-- .