(j3.2006) operator(==) and operator(/=)

[Damian Rouson]

> On Apr 13, 2016, at 12:23 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> I was a bit surprised to discover that (apparently) defining
> operator(==) does not define operator(/=), and that a scoping unit is
> not prohibited from having access to both.
> 
> Was there a conscious reason we did not (indirectly) require
> 
> ( A == B ) .eqv. ( .not. ( A /= B ) )
> 
> by specifying that only a definition of operator(==) or operator(/=) can
> be accessible in a scoping unit, and the other one is automatically
> defined?
> 
> Or was this just an oversight?
> 
> It's too late to change it now, but I'm still curious whether there was
> a thought process involved.
> 
> One might argue that also
> 
> ( A <= B ) .eqv. ( .not. ( A > B ) )
> 
> etc., but perhaps that's too much thinking to do before breakfast.


Like Tom, I can?t make any related historical statements.  I?ll simply comment that
there are several other similar cases in which the processor could supply an obvious 
implementation using a defined operator.  Given a defined operartor(+) for a type, 
the processor could supply the obvious implementation for SUM.  Given a defined 
operator(+) and a defined operator(*), the processor could supply the obvious 
implementations for DOT_PRODUCT and NORM2.  

Damian