Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Ze Administrator <groleau+news@freeshell.org> writes:

> Robert A Duff wrote:
> >>3.10.2(24), X'Access does *not* necessarily return any sort of type
> >>implicitly defined by the language (for which no comparison operations
> >>would be defined).  The wording of this clause is:
> >>
> >>   The type of X'Access is an access-to-object type, as determined by
> >>   the expected type.
> >>
> >>The way I read this is that the type of X'Access is the expected type,
> >>which could be a program-defined type, which *would* have comparison
> >>operations defined for it.

First of all, I didn't write the above.  Note the number of ">"'s.

> I'd rather agree with Robert Eachus.  If 'X' and 'Y' are
> both Integers, then X'Access obviously has to be a named
> or anonymous type that is an access Integer.  Problem is,
> there could be a dozen named types visible at that point
> which are defined that way.

In which case, there would be many "=" operators visible,
and the expression would be ambiguous.

>...Some of them could be limited.

There's no such thing as a limited access type.  ;-)
Probably there should be, but that's another story!

> You are asking the compiler to arbitrarily pick any visible
> non-limited 'access Integer' type, and use it for the comparison.

No.  If there are more than one "=" visible that take access-to-integer,
then it would be ambiguous.  In the example given, there was only one
such "=".  The point is, resolution of "=" is just like any other
subprogram.

There's no question of "arbitrarily picking" a type.  For one thing, the
compiler is picking an "=" function, not a type.  And for another thing,
the compiler is *not* expected to think, "well, all those = operators
are basically the same thing anyway, so I'll just pick one arbitrarily".

If you don't believe this is what the RM says (which was the original
question), you should quote chapter and verse.  (I admit that this is a
subtle area -- I could be wrong.)  On the other hand, if you don't
*like* what the RM says, please explain why "=" should behave
differently from other subprograms.

Note that various features *do* behave differently.  For example, as was
pointed out by somebody, there's a special rule for type conversions.
But "=" is just a function -- sometimes predefined, sometimes user
defined, so what matters is how many are visible, with what parameter
and result types (and, I claim, that's probably a good thing).

- Bob