Where Top returns a user defined reference with Implicit_Dereference, but compilation gives the following error:
simple_solar_system.adb:171:07: error: actual for aliased formal "Self" must be aliased object
simple_solar_system.adb:171:23: error: ambiguous left-hand side in assignment
simple_solar_system.adb:171:33: error: invalid operand types for operator "*"
simple_solar_system.adb:171:33: error: left operand has private type "Reference_Type" defined at maths-stacks.ads:16, instance at maths-matrix4s-stacks.ads:8
simple_solar_system.adb:171:33: error: right operand has type "Matrix4" defined at maths-matrix4s.ads:58
simple_solar_system.adb:173:07: error: actual for aliased formal "Self" must be aliased object
simple_solar_system.adb:173:23: error: ambiguous left-hand side in assignment
simple_solar_system.adb:173:33: error: invalid operand types for operator "*"
simple_solar_system.adb:173:33: error: left operand has private type "Reference_Type" defined at maths-stacks.ads:16, instance at maths-matrix4s-stacks.ads:8
simple_solar_system.adb:173:33: error: right operand has type "Matrix4" defined at maths-matrix4s.ads:58
simple_solar_system.adb:179:64: error: "Matrix_Stack" is undefined
Shouldn’t the compiler be able to work out that @ is being dereferenced?
Edit: So, even wierder.
The following compiles (once the Model_View_Stack is made aliased):
It seems like a compiler bug to me (though maybe there is some arcane rule). I see you tested casting the value. You might also try a qualifying it or also a renames object and see if those also fail/work.
Without a reproducer, there is not much to say.
However, @ is not a kind of C makro, a literal replacement. It seems that the left and right sides of Model_View_Stack.Top have different resolutions - one perhaps an access value and the other an implicit dererefence.
The interaction between @ and implicit dereference is currently being reviewed by the Ada Rapporteur Group (ARG). There do seem to be some complexities here! I anticipate that we will create an ARG GitHub issue shortly on this topic (issues can be found at GitHub · Where software is built).
In any case, it is true that @ is not a macro, but rather requires the LHS of the assignment to be evaluated to identify an object, and the @ represents a reference to that same object. But exactly when and where in these contexts implicit dereference gets applied needs to be further clarified in the Ada RM.
Well, people write about casts where there are no casts in Ada, they write about classes which are not a class in Ada. So you shouldn’t feel offended when foreign words are used.
Here, this alien wording was used to explain that @ is not a lliteral replacement of the LHS. In
X := @ * ABC;
@ evaluates identical to the LHS, whereas in
X := X * ABC;
X at the RHS might evaluate to something different depending on context.
Another way to say this: The @ is not textual replacement, but a reference to the object on the left-hand side of the assignment. The question/possible-bug here is that this reference’s dereference should contain the Implicit_Derefrence attribute of the referenced object and/or implementation thereof and interactions of said dereference.
I never expected it to be textual replacement either. I expected it to take the lhs of the assignment, and link via the ast to that on the rhs of the assignment.
Right; if the LRM were to define it on the AST/IR level it would be something like: “The @-node shall be a descendent of an ASSIGNMENT-node, and shall represent the object of the ASSIGNMENT-node to which the value will be assigned.”