Re: GCC 11 bug? lawyer needed

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

"Simon Wright" <simon@pushface.org> wrote in message 
news:lylf8ry6j5.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I agree that the original author of that program should not have used
>> "aliased" in the way that they did (they don't need the special 
>> semantics),
>> but we realize that some people would prefer to *explicitly* mark things 
>> as
>> aliased when they are going to take 'Access (and not worry about the type 
>> of
>> the parameter -- after all, it could change). That is, they don't want to
>> depend on the implicit behavior of tagged types -- or perhaps they don't
>> even know about it. Which leads to the problem that occurs here, as
>> "aliased" has slightly different meanings for functions (now just 
>> composite
>> functions) and procedures.
>
> The original code, from the Alire project, had (I've edited it slightly)
>
>   package Holders
>   is new Ada.Containers.Indefinite_Holders (Node'Class);
>
>   type Tree is
>     new Holders.Holder
>     and ...
>
>   function Root (This : Tree) return Node'Class is
>     (This.Constant_Reference);
>
> where that Constant_Reference is inherited (eventually) from
> Ada.Containers.Indefinite_Holders.Holder,
>
>   function Constant_Reference
>     (Container : aliased Holder) return Constant_Reference_Type;
>   pragma Inline (Constant_Reference);
>
> Shame it had to be there.

Constant_Reference is the case for which these semantics was designed. Hard 
to avoid it there. ;-)

Note that by returning Node'Class rather than an elementary type, you don't 
get to use the new rule tweak. Since all tagged types are by-reference (not 
by copy), the "Root" routine has to return the object that it has, which 
ultimately is part of Tree. So you actually need "aliased" on Root, since 
you are (ultimately) returning a part of the formal parameter (and which 
could become dangling if you pass in an object which is too local).

> I've just tried splattering 'aliased' wherever the compiler told me it
> was needed; it's now spreading into other packages. Ugh.

I think you need to make a copy of the return object somewhere; the obvious 
answer is to replace function Constant_Reference with function Element. Of 
course, if the return object is large enough, that could be expensive. (That 
doesn't work if you want to write the node, but the use of 
Constant_Reference doesn't allow that anyway, so in this case it doesn't 
matter.)

> The solution might just be using composition rather than inheritance.

Yeah, or using handles more as Dmitry says. In any case, it seems like some 
redesign is necessary.

                  Randy.