From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Uninitialized out parameters.
Date: Thu, 7 Apr 2016 00:12:51 +0300
Organization: Tidorum Ltd
Message-ID: <dmlcejFa7svU1@mid.individual.net>
References: <3be79ab3-ebc7-4169-9713-d50349662403@googlegroups.com>
 <a99cbcf8-8a5c-41c4-a62b-519f0d3aec60@googlegroups.com>
 <e7ddc5a9-17d7-46f4-838a-994b61380b0b@googlegroups.com>
 <alpine.DEB.2.20.1604062240350.29458@debian>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net mvjiX/LVfVJ9zZ7MvVER4w92Yf/j3h6Y0Ru+PauT8owk1DBW6q
Cancel-Lock: sha1:/A/dSojA50NkE+/2n2+Ddv8VGcA=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.1
In-Reply-To: <alpine.DEB.2.20.1604062240350.29458@debian>
Xref: news.eternal-september.org comp.lang.ada:30024
Date: 2016-04-07T00:12:51+03:00
List-Id: <comp.lang.ada>

On 16-04-06 23:53 , Stefan.Lucks@uni-weimar.de wrote:
> On Wed, 6 Apr 2016, ahlan@marriott.org wrote:
>
>> In the annotated RM, in the section concerning Null Procedures, it
>> says "There are no null functions because the return value has to be
>> constructed somehow; a function that always raises Program_Error
>> doesn't seem very useful or worth the complication" If there are no
>> null functions because a return value has to be constructed then
>> surely the same applies to null procedures that have out parameters.
>> These too should be prohibited [...]
>
> This seems to be right. It does not make much sense to allow the
> declaration of
>
>      procedure X(Formal: out T) is null;

If T has default initialization (which is now possible even for scalars, 
with the Default_Value aspect), that seems reasonable to me. It is 
equivalent to having "is begin null; end X;" as the body, which has a 
well-defined effect when there is a Default_Value, by RM 6.4.1(13.1/4) 
and other paragraphs in 6.4.1.

> while prohibiting the declaration of
>
>      function Y return R is null;

For a function, a null body is illegal (no "return" statement). Ok, 
that's a nit-pick; without that rule, this could be as defined as X, 
under the same circumstances.

> The point is, you can neither call X nor Y. Semantically, both statements
>
>      X(Actual);
>      Actual := Y;
>
> are equally useless, or at least their effect is equally undefined.

Not undefined in the case of X, when the type has a default value.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .