[J3] surprisingly PURE

[Vipul Parekh]

On Wed, Apr 22, 2020 at 3:17 AM Malcolm Cohen via J3 <
j3 at mailman.j3-fortran.org> wrote:

> ..
>
> Of course it’s also possible to avoid the problems with polymorphism via
> constraint, just forbid MOLD= to be polymorphic or of a type with a bad
> pointer definit.  I’d think that would not be very popular, **but it is
> possible**.  ..
>


Prohibiting the creation of pointer targets and allocatable variables via
local objects of polymorphic types using "MOLD=" in the context of PURE
procedures seems entirely in line with the spirit of constraint C1594 in
the current standard, particularly (6) which states, "In a pure subprogram
any designator with a base object that is .. is a dummy argument .. shall
not be used as the source-expr in a SOURCE= specifier if the designator is
of a derived type that has a pointer component at any level of component
selection".

I do think adding a constraint in a revision (202X?) that covers "MOLD="
case will be welcomed by most.  Should anyone dislike it at first, they
will appreciate it for sure if they have to deal with side effects in code
similar to Van's example which can come about in actual use based on the
current standard.

So unless anyone can readily foresee any problems with introducing such a
prohibition, I think it is worth considering a constraint along such lines
for "MOLD=" case as part of an overall "treatment plan" in Fortran
202X/202Y for this issue.

Alternately given Malcolm's idea of addressing at this at the creation of
bad pointers, I wonder if the following "big hammer" can be considered:

C1589a A local variable of a pure subprogram, or of a BLOCK construct
within a pure subprogram, shall not be of a derived type with a pointer
component at any level of component selection that is default initialized
to an initial-data-target.

Such a constraint will disallow, I think, "TYPE(T) Y" declaration in Bob's
example and "CLASS(T1), allocatable :: Y" in Van's case.  Thus get the
standard to treat it at the very root of the matter as advised by Malcolm.

Thanks,
Vipul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200422/6fadd4c0/attachment.htm>