[J3] Conditional expressions and arguments

Van Snyder van.snyder at sbcglobal.net
Thu Sep 2 00:34:49 UTC 2021


Conditional expressions can select variables, not just expressions.

This outcome would be useful in every variable-definition context, not
only as actual arguments. Add <conditional-expr>  to R902 with
appropriate constraints, at least "every <expr> in <conditional-expr>
shall be a variable."

Was it proposed and rejected, or never proposed?

Does C1004 (in 21-007r2) need to include corank? Probably not, but it's
worth pondering the question.

10.1.4p7 needs to say something about coindexing, so that C1029
continues to be meaningful. Something like "A <conditional-expr> is
coindexed if any of its <expr>s are coindexed." This would also cover
other cases (if there are any) where a coindexed object is prohibited.
If there are cases where a coindexed object is required, a more nuanced
description would be needed, such as "potentially coindexed" (for C1029
and other cases where coindexing is prohibited) if any <expr> is
coindexed, or "coindexed" if all of the <expr>s are coindexed where
coindexing is required.

C1541 needs a caveat about explicit interface.

Some of the material in C1538-C1544 needs to apply to <data-target>
(put it somewhere near C1028).

The syntax for conditional arguments introduced the .NIL. symbol.

The .NIL. outcome would be useful in an output list.

The .NIL. symbol was proposed in about 1986 to denote a disassociated
pointer (because "nil" is the reserved word in Pascal for this
purpose), especially for pointer initilization, for which there was no
provision in Fortran 90:

    real, pointer :: X => .NIL.

or

    x => .NIL.
instead of
    x => NULL()
or
    nullify ( x )

Now that we have the .NIL. symbol, is there any reason not to use it
for this purpose also? Of course, as an actual argument, it couldn't be
used for generic resolution, and maybe not at all, because it would
have no type. In pointer assignment or initialization, or as an actual
argument in the non-generic case, its type, kind, and rank could be
taken from those of the actual argument because explicit interface is
required for pointer dummy arguments. This isn't really different from
the NULL() case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210901/25cfde3a/attachment.htm>


More information about the J3 mailing list