Reference counted pointer

[certik]

Fortran has a non-owning pointer and an owning allocatable. In some cases also having a reference counted pointer (like std::shared_ptr in C++, or like the classes work in Python) would be helpful.

This has been requested a few times, some relevant past discussion:

• https://fortran-lang.discourse.group/t/ownership-for-fortran-pointers/8084.
• https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/34

[FortranFan]

It will be interesting to study the response(s) from J3/WG5 on this, especially from /DATA subgroup if at all this advances to their attention.

My hunch is this will die on the vine.

@certik, please refer back to your own post (link) at the Discourse site you cite in the original post here re: the cost of adding new features of the language.

If features are first seen as a cost, how do you think this can ever be introduced? The use case for such a feature is somewhat better convenience for the programmer and - perhaps - reduced vulnerability primarily when a derived type ( a class in OO parlance) with type-bound procedures (that is a detailed OO-approach) is employed for data management. This is all good in my own personal opinion but most readers and also those who have votes on standard committee(s) have been opponents to features with such use cases, again your own point often about "costs" and bloated language, etc. help boost the opposition,

So what exactly changes here?

[PierUgit]

This has been requested a few times, last time for example in this thread: https://fortran-lang.discourse.group/t/ownership-for-fortran-pointers/8084.

Beyond the need expressed in this thread, such pointers would help for a safer programming by avoiding memory leaks.

[klausler]

What would count as a "reference" that would change an object's reference count? Dummy argument association? Construct association? Pointer assignment? Or only new take/drop operations?

[klausler]

Reference counting makes more sense with allocatables than pointers, actually. A new CALL SHARE_ALLOC(from, to [, stat, errmsg]) would address this use case nicely, along with a minor extension to deallocation semantics.

[PierUgit]

Reference counting makes more sense with allocatables than pointers, actually. A new CALL SHARE_ALLOC(from, to [, stat, errmsg]) would address this use case nicely, along with a minor extension to deallocation semantics.

I'm not sure it is as flexible as desired (unless from can be anything, and not only an allocatable object). In addition, allocatable objects would then be potentially aliased, hurting the compiler optimizations in existing codes.

[klausler]

The shareable allocatables would have to bear a new distinguishing attribute (SHAREABLE or whatever).

[certik]

Thanks @klausler for the feedback. Yes, I think this can be done relatively nicely. We would need to prototype in a compiler to iron out the details.

@FortranFan yes, every feature should be weighted against the costs. That is best done after implementing in a compiler and testing the feature. I don't know if it is worth doing or not, but I like that we can use this proposals repository to freely discuss any feature and see how it would fit into the language and if there is enough interest in it. And just reference the issue in future discussions.

[PierUgit]

I was rather thinking about something inspired by shared_ptr, but a bit different:

• There would be a variant of the current pointers, say a "safe pointer" (e.g. integer, pointer, safe :: a(:))
• A safe pointer can be associated to any pointer (safe or not) or target object
• A non-safe pointer can not be associated to a safe pointer
• A safe pointer associated to a non-safe pointer or to a target object behaves exactly like a non-safe pointer
• If a safe pointer is being allocated
  • if this pointer or any of the associated safe pointers is nullified, or goes out of scope, or is associated to another object
    • if no other safe pointer was associated to it, the memory is released
    • if other safe pointer(s) was(were) associated to it, the memory is not released
    • (this is classical reference counting)
  • if this pointer or any of the associated safe pointers is explicitely deallocated, the memory is released and all the associated safe pointers are nullified
    • (I don't know how difficult it would be for a compiler to implement that)

EDIT: not a good idea overall, as it would allow too many cases that would just look "safe" but wouldn't be safe at all...

[klausler]

I'd need to see a prototype for that.

[jalvesz]

Reference counting makes more sense with allocatables than pointers, actually. A new CALL SHARE_ALLOC(from, to [, stat, errmsg]) would address this use case nicely, along with a minor extension to deallocation semantics.

@klausler would such approach facilitate managing C interoperability of a Fortran DT (containing allocatables instead of pointers) with C/Python structs?

I ask because a consequence of the design mentioned in the thread on Discourse was that binding the pointer arrays for interoperability became transparent with c_loc on a pointer component. Which enables also the C binded ptrs not only to expose the data but also enable modification of the array values from C/Python if needed.