# 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:** 1\
**Showing post:** 12

<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.

---

_[View the full topic](https://fortran-lang.discourse.group/t/pure-procedure-and-intent-out-polymorphic-pointer-argument/8830)._