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:
> On Tuesday, April 23, 2013 9:52:04 AM UTC-7, Simon Wright wrote:

> 
> > Yes, but there are other similar side effects: in the tests, OP wrote
> 
> > declare
> > function Make(Input : in String) return not null access Testing
> >        renames Make_EF;
> >
> > P : constant array (Positive range <>) of
> >   not null access constant Testing:=
> >     ( Make("Bob"), Make("Steve"), Make("Dave"), Make("Joey") );
> > begin
> >        null;
> > end TEST_1;
> 
> > and the code doesn't exit the declare block until all the tasks have
> > completed.
> 
> Adam says:
> > I don't see a language reason for that.

OK, after some discussion on Ada-Comment (mostly me being straightened out by Randy), I've found out what the intent of the rules was supposed to be.  I didn't really understand them before.  The RM defines accessibility levels, which correspond with masters; the intent was that when a task is allocated using an anonymous access type, the master on which the task depends is supposed to be the master "corresponding" with the accessibility level (9.3(2) isn't clear about this, but that was the intent).  And (as Egil pointed out) the accessibility level of anonymous access function results has been changed in Ada 2012--it now gets its level from the point where the function is called.  So that explains the behavior.

Based on what I now understand, I think Shark8's original example is misbehaving.  6.5(5.3) says that the accessibility level of an anonymous-access in an extended return statement is the same as the accessibility level of the function result; and since this seems to determine what masters the allocated tasks depend on, the master for the task allocated by Make_ER should be the same as the one in Make_NR and (I think) for Make_EF.  So it's a compiler bug that they're behaving differently.

I still think that anonymous access types should only be used when necessary, since there are special accessibility level rules for anonymous access types that have some surprising consequences.  There may be cases where it's beneficial to take advantage of those special rules.  But one should not use anonymous access types just because "hey, Ada lets us do it now and I can just throw in a pointer without having to think up a type name, like C programmers get to do!".  A good rule might be "don't use anonymous access types unless you've read 3.10.2 and understand it thoroughly."  (OK, that was a joke.)

                                -- Adam