Re: Overloading operator "=" for anonymous access types?

[daicrkk@googlemail.com]

Thx for the insight on anonymous access types being somewhat problematic. I have not yet gotten so far into learning the language as to see this myself.

For anyone interested I have tried to summarize my findings with regard to the example (as I did on SO). Please correct me if I'm wrong:

According to the standard, L = null, R = null, L = R as well as L.Next = R.Next should each unambiguously call the user-defined operator =. universal_access operator = must not kick in at all here.

Reason:

The operands L, R, L.Next and R.Next violate the precondition in ARM 4.5.2(9.1-9.4) for interpreting = in these expressions as to mean operator = of the unviversal_access type:

All of these operands are of an access-to-object type (access Cell, check) whose designated type is Cell (check), Cell has a user-defined primitive equality operator (check) such that

its result type is Boolean (check);
it is declared immediately within the same declaration list as Cell (check); and
at least one of its operands is an access parameter with designated type Cell (both operands are, check).
The preference rule for operator = of the universal_access type in ARM 8.6(29.1) does not apply here, since it requires "two acceptable interpretations". But because of 4.5.2, operator = of the universal_access type is not an acceptable interpretation.

So there is no choice: in all cases (even L = null) it has to be the user-defined operator =.

The example should correctly read:

...

  if Standard."="(L, null) or Standard."="(R, null) then    -- universal =
    return Standard."="(L, R);                              -- universal =
  elsif L.Value = R.Value then
    return L.Next = R.Next;                                 -- recurses OK

...

As Simon Wright pointed out, GNAT seems to run into "unbounded recursion" with the original example, which is actually the correct compiler behavior according to the standard. However SO user G_Zeus mentioned that GNAT issues an ambiguity error for L = R in a similar example, which is incorrect compiler behavior. It should have unambiguously picked the overloaded operator =.