From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,38fc011071df5a27
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-05-31 02:25:54 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-036-245.arcor-ip.NET!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Ideas for Ada 200X
Date: Sat, 31 May 2003 11:28:21 +0200
Organization: At home
Message-ID: <bb9sev$78a8t$3@ID-77047.news.dfncis.de>
References: <6a90b886.0305262344.1d558079@posting.google.com>
 <VjOAa.16051$8g5.257873@news2.e.nsc.no> <3ED41344.7090105@spam.com>
 <3ED46D81.FF62C34F@0.0> <3ED46E07.4340CABC@0.0>
 <3ED4F3FD.A0EF7079@alfred-hilscher.de>
 <1138545.LxB10ZPFul@linux1.krischik.com>
 <A6wBa.286$b8.219@nwrdny03.gnilink.net>
 <12407013.TRm0SXE9Zq@linux1.krischik.com>
 <bb71lq$6gbf6$1@ID-77047.news.dfncis.de>
 <dQidnQElALh3DUqjXTWcpg@gbronline.com>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: dialin-145-254-036-245.arcor-ip.net (145.254.36.245)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Trace: fu-berlin.de 1054373152 7612701 145.254.36.245 (16 [77047])
User-Agent: KNode/0.7.1
Xref: archiver1.google.com comp.lang.ada:38184
Date: 2003-05-31T11:28:21+02:00
List-Id: <comp.lang.ada>

Wesley Groleau wrote:

>> On the other hand, very often in C++ to implement all that ++, +=, *= etc
>> + by value vs. by reference variations becomes a heavy burden when an
>> abstract type is defined. It is also difficult to ensure that the
>> semantics of all operations is compatible.
> 
> Without actually endorsing the proposal,
> I think it would be quite simple to do.
> 
> ++  The effect of X'Inc is indistinguishable
>      from the result of
>           X := X + 1; return X;
>      including that if the above won't compile,
>      then X'Inc won't compile.
> 
> SAME paragraph, with the following substitutions:
> 
> X'Inc => X += Y  (same as)  X := X + Y;
> X'Inc => X /= Y  (same as)  X := X / Y;
> 
> etc.
> 
> No burden at all--if a compiler knows how to
> compile a construct, then it knows how to compile
> the shorthand for the construct.
> 
> Now, whether the shorthand should exist is another story.....

Sort of macro? Let me play Hyman Rosen for a while:

template <class T> void Inc (T X) { X = X + 1; } //! (:-))

OK, you have a shorthand, but it is no more effective than X := X + 1; as 
long the compiler does not know how to increment in-place. You have to go 
further:

template <class T> void Inc (T X) { X += 1; } //!! (:-))

Now you have the semantic problem back.

Maybe one could solve this from other side:

function Inc (X : in out T; By : T);
function "+" (X, Y : T) return T;
for "+" use Inc;

or better:

for "+" use Inc (X => X, By => Y);

   -- An equivalent to inlined
function "+" (X, Y : T) return T is
   Result : T := X;
begin
   Inc (Result, Y);
   return Result;
end "+";

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de