(j3.2006) Still illegal in F08?

[Malcolm Cohen]

Van Snyder wrote:
>> Huh?  There is no mention of "integer result".
>
> Yeah, it's the specification expression, not the restricted expression
> that is required by C709 to have the integer result.

Right, and that doesn't affect restricted expressions in any way I can see.

>> PRESENT is an intrinsic inquiry function, and therefore a specification 
>> inquiry,
>> and the property of A being inquired about is certainly
>> (i) NOT dependent on the upper bound of the last dimension of an assumed-size
>> array,
>> (ii) NOT deferred, and
>> (iii) NOT defined by an expression that is not a restricted expression.
>>
>> Therefore by 9(b) PRESENT(A) is a restricted expression,
>> and therefore MERGE(1,2,PRESENT(A)) is also a restricted expression
>> and thus by R728 a <specification-expr>.
>
> The argument of PRESENT is an optional dummy argument, which 7.1.11p2(2)
> says isn't a restricted expression.

Irrelevant.  9(b) is
  [a specification inquiry where each ... function argument is]
  a variable whose properties inquired about are not
  [list of exclusions which I went through above]

> Are the "properties inquired about"
> it defined by an expression that is not a restricted expression?  It's
> not obvious.

I think the property of being present or not is obviously not "defined by an 
expression", that's why I wrote it above.

In
  REAL A(23)
the upper bound of A is obviously defined by an expression.
In
  OPTIONAL A
there is no expression that *defines* whether A is present or not - it's a 
runtime property, like whether it is allocated or not.

> The properties inquired about A seem to be defined by A
> (but not by its value), which is not a restricted expression.

Irrelevant for the application of 9(b).

> Does 7.1.11p2(11) cause a problem

Since that does not affect the application of 9(b), it ... cannot cause a 
problem in the application of 9(b).

> if an optional argument is passed to
> an optional dummy argument of a specification function, which according
> to 7.1.11p2(2) is not a restricted expression?

I don't see what you are trying to get at here.

> Even if merge(size(x),0,present(a)) is OK, 7.1.11p2(2) together with
> 7.1.11p2(11) seem to make myfunc(x,a) illegal.

I agree.

>  7.1.11p2(2) is probably
> unnecessary since it's prohibited to reference an undefined value.

I could not agree less.

These restrictions are static compile-time restrictions.  We could lift them all 
and let the runtime sort it out, but that would hardly be a service to our users 
(both vendors and end-users).

In fact the flaw I can see is that 9(b) is *too lenient*; it should disallow 
properties "dependent on the presence of an optional argument", viz
  SUBROUTINE S(C)
    CHARACTER(*),OPTIONAL :: C
    INTEGER WORK(LEN(C))
this is obviously nonsense when C is not present.  Interp fodder methinks.

>  If
> we must keep it can we add something that allows an INTENT(OUT) or
> OPTIONAL dummy argument to be passed to a specification function?

Sounds like a new feature to me.  And not one I would be in favour of either - 
turning compiletime errors into runtime crashes rarely impresses.