# Pure procedure and intent(out) polymorphic pointer argument

**URL:** <https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830>\
**Category:** Uncategorized\
**Created:** [November 12, 2024, 1:05am UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830 "2024-11-12T01:05:18Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 1:05am UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/1 "2024-11-12T01:05:18Z")

</div>

```auto
module bugmod

   implicit none

   type value_t
   end type

contains

   pure subroutine fetch_ptr(ptr)
      class(value_t), intent(out), pointer :: ptr
   end subroutine

end module

```

gfortran fails to compile this code with:

```auto
Error: INTENT(OUT) argument ‘ptr’ of pure procedure ‘fetch_ptr’ at (1) may not be polymorphic

```

ifx:

```auto
bug.f90(10): warning #9000: An INTENT(OUT) dummy argument of a pure subroutine must not be polymorphic or have a polymorphic allocatable ultimate component. [PTR]
   pure subroutine fetch_ptr(ptr)
-----------------------------^

```

But why? The restriction was imposed specifically to prevent the possibility of non-pure finalizers being invoked when the actual argument to `intent(out)` is being deallocated. But why is that a problem for a `pointer`? In this case no finalizer would be called, as far as my understanding of Fortran goes. It seems that there is no reason that this should not be allowed? Is this a compiler bug or bug in the standard?

Have a good day!

Dominik

---

<div class="post-metadata">

**Author:** ![PaulT](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@PaulT](https://fortran-lang.discourse.group/u/PaulT)\
**Post date:** [November 12, 2024, 4:52pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/2 "2024-11-12T16:52:21Z")

</div>

nagfor agrees with gfortran on this one.

Fortran 2018 has the constraints:  
“C1586 An INTENT (OUT) dummy argument of a pure procedure shall not be such that finalization of the actual argument would reference an impure procedure.  
C1587 An INTENT (OUT) dummy argument of a pure procedure shall not be polymorphic or have a polymorphic allocatable ultimate component.”

I just happened to have the F2018 standard open. I am sure that there are similar contraints from F2003 onwards.

Have a good day yourself!

Paul

---

<div class="post-metadata">

**Author:** ![themos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/themos/32/521_2.png) [@themos](https://fortran-lang.discourse.group/u/themos)\
**Post date:** [November 12, 2024, 6:54pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/3 "2024-11-12T18:54:26Z")

</div>

[https://wg5-fortran.org/N2101-N2150/N2121.txt](https://wg5-fortran.org/N2101-N2150/N2121.txt), interp F08/0143

Also, F2023 (J3/24-007), 15.7 Pure procedures,

> C15106 A statement that might result in the deallocation of a polymorphic entity is not permitted in a pure procedure.

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 8:05pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/4 "2024-11-12T20:05:18Z")

</div>

Yes, I am aware of that. However, in case of `pointer`, there is no deallocation. Therefore this statement should be permitted.

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [November 12, 2024, 8:22pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/5 "2024-11-12T20:22:16Z")

</div>

But the pointer can act as a “substitute” for `allocatable` (in fact, if you change the `pointer` to `allocatable` in your code sample, there should be a similar error).

The compiler shouldn’t be expected to analyze your implementation just to determine if the pointer is acting as an alias or if the `allocate`|`deallocate` statements will be involved.

And you can always just remove the `pure` prefix or change `class` to `type` and move on.

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 8:23pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/6 "2024-11-12T20:23:38Z")

</div>

Pointer and allocatables are completely different and not intechangeable. This restriction is imposed because `intent(out)` with `allocatable` involves deallocation but not with `pointer`. There is no analysis required here.

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [November 12, 2024, 8:37pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/7 "2024-11-12T20:37:08Z")

</div>

Not “completely different”. The most significant differences are the automatic deallocation when going out of scope (for `allocatable`), and the pointing to a target (for `pointer`).

Assuming your “finalizer not involved” premise, the following would be problematic:

```fortran
use bugmod
implicit none
type(value_t), pointer :: a, b
allocate (a)
b => a
call fetch_ptr(a)
call fetch_ptr(b)
end

```

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 8:46pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/8 "2024-11-12T20:46:08Z")

</div>

Does your code involve any deallocation? Maybe my understanding of Fortran is wrong (which is totally possible since I am still learning), but I thought there is no auto-deallocation of any kind for pointers.

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [November 12, 2024, 8:53pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/9 "2024-11-12T20:53:25Z")

</div>

`call fetch_ptr(a)` will involve resetting the pointer to `undefined` status —which, without a final procedure to do the actual deallocation, is a memory leak.

The point is that the compiler has no way of knowing if your code will be used only for the “b” case and not for the “a” case.

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 8:56pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/10 "2024-11-12T20:56:37Z")

</div>

I think I am confused. When using pointers the programmer is responsible for memory management and deallocation. The object could be deallocated at a later time and another scope. You mentioned that

> [@jwmwalrus](#):
>
> The most significant differences are the automatic deallocation when (…) pointing to a target (for `pointer`).

but according to my understanding no finalizer should be called when pointer is pointed to a target – programmer is responsible for that?

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [November 12, 2024, 8:59pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/11 "2024-11-12T20:59:45Z")

</div>

Whenever there’s an `intent(out)`, a finalizer will be invoked if it exists. The `intent(out)` means “this argument should be in an initial state”.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 12, 2024, 10:10pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/12 "2024-11-12T22:10:23Z")

</div>

In case of pointer arguments, `intent` applies to the association status and not the target. It’s surprising. See this discussion: [Meaning of the intent for pointer dummy arguments](https://fortran-lang.discourse.group/t/meaning-of-the-intent-for-pointer-dummy-arguments/2328)

As to the original question, you can find some discussion on this constraint here:

> <https://github.com/j3-fortran/fortran_proposals/issues/189>
>
> Given the following constraints from the standard:
> 
> \> C1585 The function resul…t of a pure function shall not be both polymorphic and allocatable, or have a polymorphic allocatable ultimate component.
> \> C1588 An INTENT (OUT) dummy argument of a pure procedure shall not be polymorphic or have a polymorphic allocatable ultimate component.
> 
> it seems it would not be possible to write (let alone call in a pure context) a constructor for an object with a polymorphic component that is pure.
> 
> To my mind this eliminates an entire class of data structures that one would find useful (and expect to be useable) in a pure context. For example, a simple binary tree of integers might be expected to be implemented like the following.
> 
> \`\`\`Fortran
> module tree\_m
> 
> implicit none
> private
> public :: tree\_t, node, leaf
> 
> type, abstract :: tree\_t
> contains
> procedure(sum\_i), deferred :: sum
> end type
> 
> abstract interface
> pure function sum\_i(self) result(sum)
> class(tree\_t), intent(in) :: self
> integer :: sum
> end function
> end interface
> 
> type, extends(tree\_t) :: node\_t
> private
> class(tree\_t), allocatable :: left, right
> contains
> procedure :: sum =\> node\_sum
> end type
> 
> type, extends(tree\_t) :: leaf\_t
> private
> integer :: val
> contains
> procedure :: sum =\> leaf\_sum
> end type
> 
> contains
> 
> pure function node\_constructor(left, right) result(node) ! pure not allowed
> class(tree\_t), intent(in) :: left, right
> type(node\_t) :: node
> 
> allocate(node%left, source = left)
> allocate(node%right, source = right)
> end function
> 
> pure function leaf\_constructor(val) result(leaf)
> integer, intent(in) :: val
> type(leaf\_t) :: leaf
> 
> leaf%val = val
> end function
> 
> pure function node\_sum(self) result(sum)
> class(node\_t), intent(in) :: self
> integer :: sum
> 
> sum = self%left%sum() + self%right%sum()
> end function
> 
> pure function leaf\_sum(self) result(sum)
> class(leaf\_t), intent(in) :: self
> integer :: sum
> 
> sum = self%val
> end function
> 
> end module
> \`\`\`
> 
> and then be able to use it like the following in a pure context.
> 
> \`\`\`Fortran
> class(tree\_t), allocatable :: local\_tree
> integer :: total
> 
> allocate(tree, source = node(node(leaf(1), leaf(2)), leaf(3)))
> total = tree%sum()
> \`\`\`
> 
> But, even though the node constructor
> \* does not modify its inputs
> \* does not reference (let alone modify) any other entities
> \* does not perform any IO
> it still cannot be made pure due to the above constraints.
> 
> Does anyone know why (or if) these constraints are necessary? It seems most compilers are not enforcing them.

---

<div class="post-metadata">

**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\
**Post date:** [November 12, 2024, 10:30pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/13 "2024-11-12T22:30:32Z")

</div>

Also for one manual page:  
[https://www.ibm.com/docs/en/xl-fortran-linux/16.1.1?topic=attributes-intent#intent](https://www.ibm.com/docs/en/xl-fortran-linux/16.1.1?topic=attributes-intent#intent)

> If you specify a nonpointer, nonallocatable dummy argument, the INTENT attribute will have the following characteristics:
> 
> - INTENT(OUT) specifies that the dummy argument must be defined before it is referenced within the subprogram. Such a dummy argument might not become undefined on invocation of the subprogram.

> If you specify a pointer dummy argument, the INTENT attribute will have the following characteristics:
> 
> - INTENT(OUT) specifies that at the execution of the procedure, the association status of the pointer dummy argument is undefined

> If you specify an allocatable dummy argument, the INTENT attribute will have the following characteristics:
> 
> - INTENT(OUT) specifies that at the execution of the procedure, if the associated actual argument is allocated it will be deallocated.

and also some possibly related discussions (although for `allocatable` in the 2nd link):

> **[About the forbidden deallocation of a polymorphic entity in a pure procedure.](https://community.intel.com/t5/Intel-Fortran-Compiler/About-the-forbidden-deallocation-of-a-polymorphic-entity-in-a/td-p/1484958)**
>
> Hi, I've recently updated ifort from version 2021.8.0 to version 2021.9.0. Some code which was previously compiling file now gives the following error:error #5585: A statement that might result in the deallocation of a polymorphic entity is not...

> **[Can the dummy argument of a PURE subroutine with INTENT(OUT) attribute be...](https://community.intel.com/t5/Intel-Fortran-Compiler/Can-the-dummy-argument-of-a-PURE-subroutine-with-INTENT-OUT/td-p/1053361)**
>
> The following code compiles with no errors or warnings with the latest Intel Fortran compiler 2015, update 2 even with -stand compiler option: pure subroutine foo(val)
> 
> class(\*), allocatable, intent(out) :: val
> 
> allocate(val,...

Given that the `intent(out)` applies to the association status of the pointer argument (not the status of the target) and deallocation is not performed automatically upon entry, the error might be to prohibit (or reduce the chance of) possible deallocation of polymorphic variables in the procedure body (because it might involve “impure” finalization via those polymorphic variables). But then, `intent(inout), pointer` for polymorphic pointer variables also has such a possibility (while it is not prohibited), I feel the error for `intent(out), pointer` seems strange… I guess the rule for non-pointer `allocatable` dummy polymorophic arguments (involving automatic deallocation upon entry) is just used also to pointer dummy arguments as well, which seems not reasonable to me also… (maybe the same as Gronki).

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 11:01pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/14 "2024-11-12T23:01:05Z")

</div>

> [@ivanpribec](#):
>
> In case of pointer arguments, `intent` applies to the association status and not the target. It’s surprising.

I think this is exactly the wording that I should have used to express my concern. I guess I am still not that good with Fortran phraseology. But yeah, this is the reason why these errors surprised me, although I could not put it so nicely.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 12, 2024, 11:16pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/15 "2024-11-12T23:16:58Z")

</div>

Just curious, is there any reason why you can’t simply use a function?

```auto
module bugmod
    implicit none
    type value_t
    end type
    type(value_t), target :: foo
contains
    function fetch_ptr() result(ptr)
        class(value_t), pointer :: ptr
        ptr => foo
    end function
end module

program test
    use bugmod
    associate(tmp => fetch_ptr()) ! (bug?!)
       print *, associated(tmp,foo)
    end associate
end program

```

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 11:25pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/16 "2024-11-12T23:25:22Z")

</div>

I absolutely can, or I can change to

```auto
class(value_t), intent(inout), pointer :: ptr

```

and my problem will be fixed. 🙂

But if something should be permissible and the compiler (or even worse, the standard itself) throws a tantrum at me I like to find the issue and highlight it, perhaps it can be corrected. 🙂 Unless I am the one in the wrong, as it often turned out to be! I already filed a bug against gfortran.

---

<div class="post-metadata">

**Author:** ![jwmwalrus](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jwmwalrus/32/4483_2.png) [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)\
**Post date:** [November 12, 2024, 11:37pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/17 "2024-11-12T23:37:42Z")

</div>

> [@gronki](#):
>
> I think this is exactly the wording that I should have used to express my concern.

In one of my replies, I mentioned that there could be a memory leak precisely because of that —the `intent(out)` applies to the pointer, so the target is still there, but if the target is anonymous (i.e., done through allocation of that pointer), then there’ll be no way to access it anymore.

The `pure` prefix implies a lot of rules, mostly related to the general concept of [pure function](https://en.wikipedia.org/wiki/Pure_function), with some restrictions specific to Fortran (like the ones you stumbled upon).

One of the great things about Fortran 2003 and 2008, is that `pointers` could be completely avoided and `allocatables` could be used instead —except for those rare cases where only a pointer would do, like rotating binary trees and such.

You should check if you really need the `pure` prefix or the `pointer` attribute, or even if the subroutine could be a function instead.

---

<div class="post-metadata">

**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\
**Post date:** [November 12, 2024, 11:43pm UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/18 "2024-11-12T23:43:55Z")

</div>

I am working on a parser and I deal with a lot of data structures, therefore I consciously choose to use `pointer`s to avoid copies (typically they are `pointer`s to `allocatable`s actually, but that is out of the topic).

I just find it very helpful to ask the questions about “edge cases”, since there are three possible outcomes and each of them is beneficial:

- (most often) my knowledge in Fortran fails me and I do something obviously stupid → I learn
- (sometimes) there is a compiler error and I can file a bug report → Fortran tooling improves
- (rare but not impossible) there is something not considered or poorly worded in a standard and this can get clarified → Fortran as a whole improves

Regarding the use of `pure`, I like to use it wherever possible, until I really need to get things “impure” 🙂 In this case, it just clashed with my understanding of _why_ the restriction for polymorphic `intent(out)` arguments is imposed – I felt like there is no reason for the case of `pointer`.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 13, 2024, 12:40am UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/19 "2024-11-13T00:40:40Z")

</div>

> [@gronki](#):
>
> But yeah, this is the reason why these errors surprised me, although I could not put it so nicely.

Actually I also misread your question and the answers in this thread. The error that compilers return isn’t because of the pointer attribute. You get the same errors without it: [Compiler Explorer](https://godbolt.org/z/z3zYbWvYa)

Looking into MFE (the 2023 version), it states:

> Declaring a procedure to be pure is an assertion that the procedure
> 
> - if a function, does not alter any dummy argument, unless it has the `value` attribute (Section 20.8);
> - does not alter any part of a variable accessed by host or use association;
> - contains no local variable with a `save` attribute;
> - performs no operations on an external file (Chapters 10 and 12);
> - contains no stop statement
> - cannot cause the exectuion of an image control statement
> - does not reference an impure procedure
> 
> To ensure that these requirements are met and that a compiler can easily check that this is so, there are the following further rules:
> 
> - any dummy argument that is a procedure, and any procedure referenced, is pure;
> - the intent of a dummy argument is declared unless it is a procedure, a pointer, or has the `value` attribute (Section 20.8), and this intent must be `in` in the case of a function;
> - any internal procedure is pure;
> - the procedure do not reference an impure procedure through finalization (Section 15.11) of its function result or an intent `out` dummy argument;
> - the procedure does not have an intent `out` dummy argument that is polymorphic or has a polymorphic allocatable ultimate component;
> - for a function, the result is not polymorphic and allocatable, and does not have a polymorphic allocatable component; and
> - …

So the issue here, is that if you had a finalizable type, that finalizer could be impure. This may not be obvious, but finalization

> … also occurs (in the called procedure) when the object is passed to an intent `out` dummy argument, …

just like you clarified in the original post.

Bringing us back to your question, why isn’t a polymorphic **pointer** intent `out` dummy argument permitted, or why can’t the constraint C1587 (see @PaulT’s post) be relaxed? The target hasn’t been modified, so why would this be somehow impure?

Maybe the answer lies in what @septc says,

> If you specify a pointer dummy argument, the INTENT attribute will have the following characteristics:
> 
> - INTENT(OUT) specifies that at the execution of the procedure, the association status of the pointer dummy argument is undefined

and as @jwmwalrus spelled out:

> I mentioned that there could be a memory leak precisely because of that —the `intent(out)` applies to the pointer, so the target is still there, but if the target is anonymous (i.e., done through allocation of that pointer), then there’ll be no way to access it anymore.

Making a pointer became undefined means changing a descriptor. The actual type would become lost on entry. It could invalidate other variables in your program. In contrast intent `inout` asserts you’ll be taking control of the pointers association status and target, and and you’re fully aware how. Just one way of reasoning about this.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [November 13, 2024, 8:33am UTC](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830/20 "2024-11-13T08:33:51Z")

</div>

> [@jwmwalrus](#):
>
> In one of my replies, I mentioned that there could be a memory leak precisely because of that —the `intent(out)` applies to the pointer, so the target is still there, but if the target is anonymous (i.e., done through allocation of that pointer), then there’ll be no way to access it anymore.

Nevertheless, this is allowed for non-polymorphic types without polymorphic allocatable components:

```auto
   pure subroutine fetch_ptr(ptr)
      integer, intent(out), pointer :: ptr
      ! ...
   end subroutine

```

So this doesn’t seem to be the issue in @gronki’s case. It’s because of the polymorphic type (`class(value_t)`) and C1587 that it doesn’t work.

[Next page](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830.md?page=2)