Re: Aspect location in expression function.

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:t5oigj$pag$1@dont-email.me...
> Le 14/05/2022 à 13:47, Blady a écrit :
>> Hello,
>>
>> I'm puzzled when I want to changed a function body with aspects to an 
>> expression function, for instance:
>>
>> function Length (S : Some_Tagged_Tyoe) return Natural
>>  with Pre => S.Valid
>>  is
>>  begin
>>  return S.Length;
>>  end;
>>
>> have to be changed in:
>>
>> function Length (S : Some_Tagged_Tyoe) return Natural
>>  is (S.Length)
>>  with Pre => S.Valid;
>>
>> The location of the aspect has moved to the end.
>>
>> I'd like simply replace the begin block by the expression, as:
>>
>> function Length (S : Some_Tagged_Tyoe) return Natural
>>  with Pre => S.Valid
>>  is (S.Length);
>>
>> What could be any reasons not to permit it?
>
> What you say is logical if you think of an expression function as a body; 
> however, it is more like a specification (it can appear in a package spec, 
> although it can complete a specification), so the place where the aspect 
> appears makes sense. And it would be confusing to allow the aspect in two 
> different places. It is the same for separate bodies of subprograms.

To make a functioning :LR grammar for Ada, I *had* to allow the aspect 
specification in both places, and then make one of them illegal. Which is 
more work than just allowing in either place. So I guess it is a matter of 
perspective. :-)

To the OP: we discussed placement of aspect specifications ad-nausem, as 
issues like this always were coming up. There is no consistent rule that 
really works well, because one does not want small things following large 
sets of aspect specs -- they can get lost and overlooked.

For instance, one puts aspect specifications after "is abstract" as 
otherwise that could be lost after a lengthy precondition expression (and 
it's too important to be lost). See how that could happen in the following 
(illegal) declaration:

    procedure P (A, B ,,,)
       with Pre => <very long expression that extends over several lines 
here>
       is abstract;

So something like this (and "is null" as well) require the Pre at the end:

    procedure P (A, B ,,,)
       is abstract
       with Pre => <very long expression that extends over several lines 
here>;

Expression functions generally follow the same rules as the older null 
procedures, thus they ended up with the same positioning. It's not as 
obvious a case here, since the return expression can also be long, but we 
thought it should be consistent.

BTW, I don't think there ever is a reason to go from an expression with a 
normal body to an expression function (assuming the body is legal). A normal 
body is more readable and less of a hassle during maintenance. The advantage 
of an expression function is to use it in places where a regular body is not 
allowed and/or just to be lazy writing the body - neither of which would 
ever require changing *to* an expression function. Maintenance might require 
changing *from* an expression function if the body has gotten too complex 
(for instance, needs a variable declaration), but that generally will 
require moving the function as well so "ease" of doing so isn't very 
relevant.

                                Randy.