Re: Is this a bug?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qumug8$1bsj$1@gioia.aioe.org...
> On 2020-01-03 08:35, reinert wrote:
...
>> But what is really the problem of prohibiting to include above:
>>
>> function a(x: rec1_t) return Integer is (5);
>>
>> ?
>>
>> This is similar to that the following is not legal:
>>
>> type rec1_t is tagged record
>>     a : Integer := 2;
>>     b : Integer := 2;
>>     a : Integer := 5; -- is not legal.
>> end record;
>>
>> ?
>
> Yes, but that is was not possible, because in Ada 95 the function "a" did 
> not conflict with members. The change in Ada 2005 introduced dot notation 
> and thus the conflict.

It also doesn't really fix the problem unless one starts breaking privacy. 
It's not just direct local declarations that cause problems, but also 
inherited routines and class-wide routines associated with ancestors. And 
since components can become visible at later points, you can also have 
something that is legal in a specification be illegal in a body (especially 
possible for child units).

For instance, if you have something like:

    package P is
       type Root is tagged private;
       function C1 (A : Root) return Boolean;
       function C2 (B : Root'Class) return Boolean;
   private
       type Root is tagged record
            C3 : Natural;
       end record;
   end P;

Then, for

    Obj : Root;

Obj.C1 and Obj.C2 are legal.

    package P.Child is
          type New_Type is new Root with record
                 ??? : Natural;
          end record;
          function C3 (A : New_Type) return Boolean; -- Nope.
    end P.Child;

New_Type cannot have components named C1 or C2, so if ??? has either of 
those names, it has to be illegal. In addition, the function has to be 
banned because the component C3 will be visible in the body of P.Child. (??? 
is illegal if it is C3.)

Because of the cases illustrated above, you also now have much more 
significant maintenance problem. Imagine that P is some package out of your 
control, like a GTKAda or even an Ada.Container package.

As Ada stands, one can add a subprogram to a package without having too 
worry much about incompatibility. Conflicts are possible, but only matter if 
the entire profile of the new subprogram matches. In cases like this, *any* 
matching causes problems. That's because objects aren't overloadable in Ada, 
so a component conflicts with any subprogram with the same name and prefix 
parameter.

One can imagine making objects overloadable in Ada to avoid this problem 
(the language would probably have been better if that had been the case), 
but that can lead to the worst possible incompatibility: a program that 
compiles and means something different than it does in current Ada. To avoid 
that, you have to have some additional complex rules. And, of course if this 
was done, we don't need the original rule at all (just let true conflicts 
happen). So we're pretty much back where we started from.

In a language designed from the ground up to have this sort of prefix 
notation for functions, there'd be no problem. But Ada isn't that language.

                                   Randy.