Re: Will "renames" increase program size?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 16 Jun 2011 03:18:14 -0700 (PDT), AdaMagica wrote:

>> procedure Shame is
>> � �type T is array (Integer range <>) of Integer;
>> � �A : T := (0 => 0, 1 => 1);
>> � �subtype S is T (1..2);
>> � �B : S renames A;
>> begin
>> � �Put_Line (Integer'Image (B (0))); -- Surprise, 0 is a legal index of S!
>> end Shame;
> 
> Yes, agreed, that's annoying and confusing. Perhaps such a renaming
> should be forbidden. Don't know what other consequences such a rule
> would have, which other rules would have to be adapted. Think of
> generics... (I know you dislike generics.)

(:-))

I think it would be difficult to forbid, because renaming that changes view
is extremely useful for tagged types. E.g.

   if X in S'Class then
      declare
         Y : S'Class renames S'Class (X);
      begin

I always wished a cleaner and safer construct for this, then we could
indeed disable renaming to a view altogether.

Luckily, this one is illegal:

   type T is access all Integer;
   subtype S is not null T;
   P1 : T := null;
   P2 : S renames S (P1);

>> Regarding the visibility rules, the design bug is that the new name of a
>> thing shall not hide any other names of it in any context. In the example
>> above P1.End_Error should not have hidden P2.End_Error. (I don't know why
>> this has not been fixed long time ago, because it would be a really minor
>> language change, which would not break any existing code).
> 
> You request that resolution would not be via names, but via entities.
> Thus when there are several homonymes visible at the same time, the
> compiler would have to check whether all these names actually specify
> the same entity.

Yes.

> Don't know whether this would make overload
> resolution more difficult.

Maybe it would not, because the actions need only to be undertaken when a
conflict is detected. Then the compiler would weed the list of conflicting
names of same entities. That should not even slower the compilation
(provided the feature would not be abused).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de