Version 1.1 of 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); --
procedure Bar (X : access Integer := Default'access); --
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. ;-)
****************************************************************
Questions? Ask the ACAA Technical Agent