"J-P. Rosen" <
[email protected]> wrote in message news:t5oigj$pag$
[email protected]...
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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)