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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c3a7c1845ec5caf9
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/26
Message-ID: <E99Kou.Hn8@world.std.com>#1/1
X-Deja-AN: 237580273
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <mheaney-ya023680002404971929220001@news.ni.net> <dewar.861971395@merv>
 <mheaney-ya023680002504972002170001@news.ni.net>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-04-26T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <mheaney-ya023680002504972002170001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>Fair enough, but let me ask you this.  If you didn't have backwards
>compatibility as a goal, then would you have made it the rule that types
>compose whose equality operator had been redefined?

Well, compatibility wasn't much of an issue specifically for "=",
because it wasn't allowed for non-lim types in Ada 83.  But if "="
composes, then one asks oneself whether "<" composes, and so on, and
*those* questions do raise backward compatibility issues.  In
retrospect, I admit that I probably would go further, at least for "=",
in terms of composability.  But I'm not exactly sure where to draw the
line.

- Bob