Re: Interresting difference in Normal-Returns/Expression-Functions and Extended-Returns.

[Adam Beneschan <adam@irvine.com>]

On Wednesday, May 1, 2013 7:38:29 PM UTC-7, Randy Brukardt wrote:

> I don't understand. The anonymous access type is declared in the block, as 
> the master of an access return is that of the point of call [it's passed 
> into the function if necessary]. (That's changed in Ada 2012, but the 
> previous definition was nonsense.) That's the master of the allocators.

I think I covered this in my previous response to Egil, but it doesn't appear to me that the RM says this is the master of an allocated task.  That's defined in 9.3(2), which says the master of an allocated task is the master that elaborates the anonymous access type declaration.  Maybe it's the intent that the "anonymous access type declaration" involved here is the one in the block, but there are multiple anonymous access type declarations involved--the one declared with the FUNCTION declaration, and the one declared in the block--and I don't know of any reason in the RM that says the "given access type" is one or the other.  My thinking is that it should be the obvious one--the declaration that is referred to at the point where the allocator occurs, which would be the function result type.

The same problem occurs with extended return:

> BTW, I don't think the extended return should be different, but I have no 
> interest in figuring out whether it could or not. It probably depends on 
> exactly how/where the allocator is written.

The problem is that the extended return introduces yet a third anonymous access type declaration.  Apparently you think that this shouldn't change things, and it makes sense that it shouldn't.  But the way 9.3(2) is written, I think it does.

I think the answer is just that 9.3(2) is broken and needs to be fixed.  It works fine for named access types, but leads to possibly undesirable consequences with anonymous access types.  In fact, this rule essentially hasn't changed since Ada 83 (RM83 9.4(2)), when of course there were no anonymous access types.  Either 9.3(2) needs to be rewritten to specify exactly what is supposed to happen when an allocator for an anonymous access type creates a task, or it should just be illegal to use an allocator for an anonymous-access-to-task (or to a type containing a task).  I wouldn't be opposed to the latter alternative.  It wouldn't be backward compatible, but at least it would accomplish this purpose:

> No human can figure these things out, so please don't use them and save the 
> brain of an ARG member. ;-)

                                  -- Adam