# Allow newunit to allocate an integer variable

**URL:** <https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451>\
**Category:** Language enhancement\
**Created:** [August 8, 2024, 12:42pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451 "2024-08-08T12:42:54Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [August 11, 2024, 11:42am UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/9 "2024-08-11T11:42:33Z")

</div>

The `print`, `write`, `read`, `allocate`, and `deallocate` statements can take any number of “arguments” of any type, kind, and rank, and Fortran would be much less convenient if those statements did not have such flexibility. I think the closest a procedure can come to this is to [have many `class(*),intent(in),optional` arguments](https://fortran-lang.discourse.group/t/writing-to-a-file-or-a-string-with-the-same-function/8448/8). It would be nice if a non-intrinsic function could have a return type that depends on a `kind` argument that is known at compile time, as  
`real(a [, kind])` does. Does the intrinsics proposal allow that?

---

_[View the full topic](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451)._