[J3] surprisingly PURE
rpcorbett at att.net
Wed Apr 22 03:43:23 EDT 2020
A possible fix is to prohibit the
name of a derived type with a
non-null default initializer for a
data pointer component from
appearing in a pure subprogram.
It is a big hammer, but it fixes
the problem. It is an easy
constraint to check.
I have considered about a dozen
possible fixes for the problem,
each of which has some
drawbacks. For the Fortran 2018
interpretation, I recommend
punting. The interp should add a
requirement, but not a constraint,
prohibiting operations that can
change the global state except
through the dummy arguments.
I have been told repeatedly that
we should not add constraints
For Fortran 202x, we should add
one or more constraints to
prohibit the bad behavior. The
constraints will need to be
broader than strictly necessary
to ensure that they can be
checked statically. Previous
editions of the standard have
made similar changes to the
definition of pure subprograms.
I have tried to construct
examples where it seems
desirable to have a default
initializer other than null for
a data pointer component.
I have yet to find a
> On Apr 21, 2020, at 11:13 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> Pointers allow one to do things with pure procedures that one might think violate the "principle" of PURE.
> One can pass an object of a type that has a pointer component, with the component associated with a variable that's not mentioned in the argument list, and then the procedure can assign a valueto that variable (or undefine it).
> real, target :: X = 1.0
> type :: T
> real, pointer :: X
> end type T
> type(t) :: V
> print *, 'Before call, X =', x
> v%x => x
> call s ( v )
> print *, 'Afer call, X =', x
> subroutine S ( A )
> type(t), intent(inout) :: A
> a%x = 42.0
> end subroutine S
> This has been with us since the beginning of PURE, but some might say "that's not pure!"
> Is this really different from changing X by way of a pointer component with default initialization that associates it with X?
> Bob's example is a bit diffent because it doesn't involve a side effect using a dummy argument that some might argue violates the spirit of "pure."
> But, taking these together, and the potential problems with polymorphism that appear not to be addressable with constraints, is there really anything the standard can do to plug every loophole?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3