Re: Is this a bug?

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:h6uum4F2481U1@mid.individual.net...
> On 2019-12-30 19:51, Anh Vo wrote:
>> On Monday, December 30, 2019 at 7:44:37 AM UTC-8, reinert wrote:
>>> Hello,
>>>
>>> assume the following Ada procedure:
>>> ------------------------------------------------------------------------------
>>> with Text_IO;
>>> procedure test1 is
>>> package test_package is
>>>   type rec1_t is tagged record
>>>     a : integer := 2;
>>> -- b : integer := 2;
>>>   end record;
>>>   function a(x : rec1_t) return integer is (3);
>>>   rec1 : rec1_t;
>>> end test_package;
>>> begin
>>>    Text_IO.Put(" test_package.rec1: " & 
>>> integer'image(test_package.rec1.a));
>>> end test1;
>>> -------------------------------------------------------------------------------
>>>
>>> It gives (for mye computer):
>>>
>>> test_package.rec1:  2
>>>
>>> If I change the statement
>>>
>>> "a : integer := 2;"
>>>
>>> to
>>>
>>> "b : integer := 2;"
>>>
>>> then I get:
>>>
>>> test_package.rec1:  3
>>>
>>> Is this reasonable?  Bug?
>>>
>>> reinert
>>
>> No, the compiler behaves correctly. In fact, if tagged record is
>> replaced by record, the latter case will be rejected.
>
> Yes.
>
> When rec1_t is tagged, the "selected component" text "test_package.rec1.a" 
> could refer either to the rec1_t-component "a" or to the subprogram 
> (function) "a". In RM 4.1.3(9.1/2) and RM 4.1.3(9.2/3), the latter case is 
> available only under the condition that the tagged record type (rec1_t) 
> does not have a (visible) component with the name "a". This means that the 
> ambiguity is resolved in favour of the component "a", which has the value 
> 2.
>
> One could ask, why is such an ambiguity not rejected (made illegal)? 
> Probably because such an illegality rule would have made many illegal many 
> Ada programs that were legal before the introduction of the 
> "object.operation" syntax for tagged-record objects.

The other reason is that there isn't any alternative notation available for 
components, whereas there is an alternative method for function calls. Ergo, 
we assume that you mean a component if both are available -- otherwise, it 
would be impossible to access a component at all if there is a function with 
the same name visible. Since that function wouldn't even have to be in the 
same scope, there would be a significant maintainance hazard.

Moral: This is another reason to make everything a private type (and also to 
not use prefixed notation with types that aren't private).

                                      Randy.