Version 1.2 of ai12s/ai12-0221-1.txt

Unformatted version of ai12s/ai12-0221-1.txt version 1.2
Other versions for file ai12s/ai12-0221-1.txt

!standard 6.1(19)          17-04-10 AI12-0221-1/01
!class Amendment 17-04-10
!status work item 17-04-10
!status received 16-12-23
!priority Very Low
!difficulty Easy
!subject Defaults for in out parameters
!summary
Allow defaults on parameters of all modes.
!problem
Ada does not allow parameters of mode "in out" or "out" to have a default.
If we want an in out parameter to have a default, we have to make it an in parameter and pass an access value.
package P is Default : aliased Integer := 1;
procedure Foo (X : in out Integer := Default); -- Illegal.
procedure Bar (X : access Integer := Default'access); -- OK
end P;
!proposal
(See Summary.)
!wording
Delete 6.1(19).
[Editor's note: Do we need to enhance 6.4.1 to detect problems with defaults that could get modified?? Or is that already covered??]
!discussion
This often happens for storage pool parameters; a storage pool object has to be a variable in order to be usable in a Storage_Pool aspect specification (see 13.11(15)). Thus, a storage pool passed as an "in" parameter cannot be used to define the pool of an access type. But that means that a default cannot be given -- and usually these parameters are not used.
Similar issues ocur for similar abstractions, such as a pool of tasks.
[Editor's note: I once ran into this as a problem with some version of Claw. I no longer remember the details beyond that it had something to do with a call-back routine where the mode had to be "in out" for some reason out of our control.]
---
It is thought that the reason that is not allowed in Ada because it hides an update to the actual parameter. Problems caused by that would be partially mitigated by the 6.4.1 anti-aliasing rules (it would be difficult to cause an order dependency with such a parameter), and it's not a problem for by-reference types (we judged that the anti-aliasing rules shouldn't apply to such parameters, and there's little reason to think this is different); but the underlying problem of an update invisible to the reader remains.
[Editor's musing: It's interesting that an invisible update is considered a problem, but invisible usage of default expressions is not considered a problem. They seem pretty similar on the surface, especially once order dependencies are removed as a concern. Not sure what to think here...]
!ASIS
Unsure.
!ACATS test
An ACATS C-Test is needed to check that the new capabilities are supported.
!appendix

From: Brad Moore
Sent: Friday, December 23, 2016  3:06 PM

In Ada 2005 we allowed functions to have "in out" parameters in part 
to eliminate the need to use access types.
 
I just noticed another case where the language currently encourages 
you to use access types, when an in out parameter would have been preferred.
 
We currently do not allow in out parameters to have a default.

in 6.1(19) we have "A default_expression is only allowed in a 
parameter_specification for a formal parameter of mode in."

If we want an in out parameter to have a default, we have to make it 
an in parameter and pass an access value.

eg.


package P is
   Default : aliased Integer := 1;
   type Integer_Access is access all Integer;
   
   procedure Foo (X : in out Integer := Default);        <= Illegal

   procedure Bar1 (X : Integer_Access := Default'Access); <= OK
   
   procedure Bar2 (X : access Integer := Default'Access); <= OK

end P;

I ran into this in my own code where I have a task pool abstraction, and I
wanted to have a default task pool object, that could be passed into my
library functions as in out objects. I did not like that I had to declare
the default task pool to be aliased (and all others as well), and having to
use 'Access on all task pool objects to pass them into these libraries, if I
want to have a default.

I don't know if this has been considered recently during Ada 2005 or later,
but it seems like a bit of a hole that would be nice to fix.

If this is something that others agree should be looked at, I should probably
submit this to ada comment.

****************************************************************

From: Bob Duff
Sent: Friday, December 23, 2016  3:46 PM

> We currently do not allow in out parameters to have a default.

It was allowed in Green or Preliminary Ada, around 1980 or so.

****************************************************************

From: Tucker Taft
Sent: Saturday, December 24, 2016  10:08 AM

>> If we want an in out parameter to have a default, we have to make it 
>> an in parameter and pass an access value.

Alternatively you could provide a second version that has one less parameter.
That is the "Java" approach to default parameters.  Not a great solution in
general, but might be adequate for the few times you need this capability.

...
> I don't know if this has been considered recently during Ada 2005 or 
> later, but it seems like a bit of a hole that would be nice to fix.
>
> If this is something that others agree should be looked at, I should
> probably submit this to ada comment.

I presume the reason it was eliminated from Ada 83 is because it hides an
update to the actual parameter.  I think that argument still applies.  I agree
that is somewhat inconsistent w.r.t. access types, but I would suspect the
most common default for an access type parameter is "null."

****************************************************************

From: Brad Moore
Sent: Saturday, December 24, 2016  10:48 AM

Good to have an alternative, but its not clear to me which one I like less.
As you mention though, this is probably not something that comes up often.

Given these alternatives, I think the best alternative, is neither of these,
but instead, dont have a default, and force the programmer to always specify
which object they want to use. At least for the abstraction I am working on.

If we had defaults for in out parameters, I probably would have chosen that,
but given that is not a choice, the most appealing to me is to provide a
simple uncluttered API, devoid as much as possible of access parameters.

Maybe those alternatives are adequate enough.

****************************************************************

From: Randy Brukardt
Sent: Monday, April 10, 2017  11:45 PM

I didn't remember that, which caused me to grab our shelf copy of Ada 80
(dated July 1980). And Ada-80 says that "If the parameter declaration has mode
in, and only then, it may include an initialization." (I'd reference the
paragraph number, but there aren't any in Ada 80! It's on page 6-2, 2nd
paragraph.)

It's certainly possible that the 1978 version didn't have that rule; we used
to have a xeroxed copy of it around somewhere, but it's long since been
recycled. (Janus/Ada started in the fall of 1980; I'm pretty sure we worked
from the Ada 80 as soon as it morphed from a class-assigned project.)

P.S. This should be a candidate for the least important on-topic ARG
message. ;-)

****************************************************************

From: John Barnes
Sent: Tuesday, April 11, 2017  4:17 AM

Looking in my attic I find:

Preliminary Green (April 78) says (page 37)

For in parameters, the parameter definition  may also include a specification
of an expression that is implicitly assigned to the parameter if no explicit
value is given in the call.


Green (March 79) says (page 6-3)

Exactly same as for Preliminary Green


Preliminary Ada (June 1979) says (page 6-3)

For in parameters, the parameter declaration  may also include a specification
of a default expression, whose value is implicitly assigned to the parameter
if no explicit value is given in the call.


Ada (July 1980) says (page 6-3) nothing about defaults at all. That section
was rewritten to rant about passing mechanisms. However, a new section 6.4.2
on page 6-7 says

If a subprogram declaration specifies a default value for an in parameter,
then the corresponding parameter may be omitted from a call.

====

So it looks as if in out parameters could never have defaults.

****************************************************************

From: Bob Duff
Sent: Tuesday, April 11, 2017  9:28 AM

> So it looks as if in out parameters could never have defaults.

I remember being disappointed when that feature was removed.
I suppose I must be imagining things.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, April 11, 2017  2:46 PM

...
> Ada (July 1980) says (page 6-3) nothing about defaults at all. That 
> section was rewritten to rant about passing mechanisms.

The second paragraph on page 6-2 includes If the parameter declaration has
mode in, and only then, it may include an initialization.

Unless there is a difference between the first and second printing (the
copy I have says it is from a second printing of November 1980), I'd expect
that you'd find the rule there in your copy as well. Probably it moved to 6.1
(where it remains today) between Preliminary Ada and original Ada.

****************************************************************

Questions? Ask the ACAA Technical Agent