Ownership for Fortran pointers

Language enhancement
38

“safe” in this context (and many other semantic and technical contexts that I won’t get into for the sake of brevity) is utterly a weasel word and one can only hope a mere working contractor such as J3 for the ISO working group (WG5) for Fortran will always gain the sense from now on to stay away from such words for the benefit of this language and its practitioners.

Based on many communications by different Fortranners on various platforms (including comp.lang.fortran) and discussions (including at J3 working meetings) across many years and including this thread initiated by @hkvzjal , it appears the practitioners of Fortran can really benefit from a language standard revision which introduces a notion of pointer-spec that can be envisioned as somewhat analogous, at least syntactically, to intent-spec (INTENT(IN), INTENT(IN OUT), etc.).

Thus, with a pointer-spec which may take certain labels, let’s just call them here for the sake of keeping the discourse open as thing one, thing two, thing three

Rnnn pointer-spec is thing_one
                  or thing_two
                  or thing_three

Now, if I had my wish, I would term thing_one as ALIAS; thing_two as CONST_DATA; and thing_three as CONST_REF where:

  • ALIAS implies the object with the pointer attribute in an alias to another object (one that is a target), thus it is not the “owner” of the data. Thus the object with ALIAS spec cannot appear in ALLOCATE and DEALLOCATE statements. Note this is in effect close to or same as the desired facility by OP in this thread,
  • CONST_REF implies the pointer object cannot appear in any pointer association context other than initialization. Note this is what is in effect with INTENT(IN) and POINTER in the current standard but which has proved both confusing and inadequate for many Fortranners.
  • CONST_DATA implies the pointer object cannot appear in any variable definition context other than initialization.

The standard may then specify suitable semantic requirements, preferably in the form of numbered constraints, connected with pointer-spec that enable Fortranners to consume the POINTER attribute with significantly reduced vulnerabilities i.e., make the use of pointers effectively more “safe”.

So with a feature set along such lines, a Fortranner may author code such as

  ..
  real, target :: some_data(2,3)
  real, pointer( alias, const_ref ) :: pdata(:,:) => some_data  !<-- now pdata shall not appear in any pointer association context including `ALLOCATE` and `DEALLOCATE` statements
  ..

which then restricts the object pdata from being allocated or deallocated and from being associated with other targets.

And in case like with OP here who seeks to work with data “containers” (what is referred to as mytype in the original post, the data “container” may possibly be defined as

   type :: data_container_t
      ..
      real, allocatable :: data(:,:)
      real, pointer( alias ) :: pdata(:,:)
      ..

which will then allow the pdata component to point to targets that may be data sources elsewhere (possibly remote). pdata may even point to the data component itself. In effect, pdata shall serve as how pointers were intended in Fortran which is primarily as aliases. But the point to note is the language directly allows an indication pdata is not the “owner” of the data and it is clear to the author any finalization of such a container need not ponder over the question as to whether to deallocate the memory holding the data.

But Fortranners have also expressed a need in certain contexts to use aliases to immutable data. This appears another use case that the language should try to serve. This can also possibly allow pointers to associate with named constants that are targets. This will be useful for Fortranners, from what I have come across from feedback, with safely working with constant data, a key aspect in certain coding instructions present in scientific and technical computing e.g.,

   integer, parameter, target :: foo(*) = [ 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, .. ]
   ..
   integer, pointer ( alias, const_data, const_ref ) :: bar(:) => foo(1:10)
   ..

TL;DR:

  1. Do not use weasel words like “safe”, “concurrent”, “REAL64” etc. with Fortran features. To borrow from Wikipedia, these create “an impression that something specific and meaningful has been” added to the language, “when in fact only a vague, ambiguous, or irrelevant feature has been” introduced

  2. Within the context of this thread with POINTERs in Fortran, Fortranners would benefit if the Community can think more broadly and develop something that introduces a set of facilities which make the use of pointers less vulnerable than at present in some specific and stated issues, like I explain above.

3 Likes