# Allow newunit to allocate an integer variable **URL:** \ **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:** 10\ **Page:** 1
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [August 8, 2024, 12:42pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/1 "2024-08-08T12:42:54Z")
Could the `newunit` specifier of the `open` statement be extended so that if an `allocatable` `integer` variable that has not been `allocated` is passed, it is allocated by the `open` statement? For example, in the code below, I would like the invalid line to be valid. ```auto implicit none ! integer, allocatable :: iu ! invalid integer :: iu open (newunit=iu, file="temp.txt", action="write") write (iu,*) "hello" end ``` A benefit of using an allocatable integer as a unit number is that when you write `call foo(x, y, log_unit)` you can turn logging on or off by allocating (or not) `log_unit` before calling `foo`, since [an unallocated variable passed as an argument is not PRESENT](https://fortran-lang.discourse.group/t/an-unallocated-variable-passed-as-an-argument-is-not-present/1724). You don’t need separate call statements for logging or not logging. This proposal is motivated by the current thread [Writing to a file or a string with the same function](https://fortran-lang.discourse.group/t/writing-to-a-file-or-a-string-with-the-same-function/8448/1). ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [August 8, 2024, 12:56pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/2 "2024-08-08T12:56:21Z")
Interesting idea. There is some precedence here, as we now allow unallocated, allocatable, deferred-length character variables in a handful of places now. That said, your motivating use case/design is still achievable without the feature, even if the opening of the file would take multiple lines, so I don’t see a high priority on this. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [August 8, 2024, 2:36pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/3 "2024-08-08T14:36:21Z")
I thought of another rationale for my proposal. Before a statement `open (newunit=iu, file="temp.txt", action="write")` the variable `iu` typically will not have been set. If you allow `iu` to be `allocatable`, then using it before the `open` statement will cause a run-time error. If `iu` is not `allocatable`, using it before it is initialized may pass unnoticed. ---
**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\ **Post date:** [August 10, 2024, 12:15am UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/4 "2024-08-10T00:15:44Z")
There’s a related concept (I think) in which an unallocated character string can’t be used for the `iomsg` argument of the `open` statement. The issue is that the max/actual length of `iomsg` is unknown, so fixed-length and preallocation are not good solutions. Under the hood does it make sense though? My understanding is that these would be passed by reference, so passing an unallocated variable as an argument has no meaning. Would you require the compiler to identify such a case and implicitly allocate it before passing? But if it’s allocated before passing, how would the compiler ensure the allocation conforms with what the called function needs? ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [August 10, 2024, 1:25am UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/5 "2024-08-10T01:25:07Z")
> [@Machalot](#): > > There’s a related concept (I think) in which an unallocated @Machalot , Thankfully the current standard revision, Fortran 2023, has addressed this aspect You can look for the feature in compilers seeking to support Fortran 2023 when they decide do so, this year or X years from now. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 10, 2024, 3:00am UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/6 "2024-08-10T03:00:54Z")
> [@Machalot](#): > > My understanding is that these would be passed by reference, so passing an unallocated variable as an argument has no meaning. It is routine to pass an unallocated argument to a subroutine, but the dummy argument must have the allocatable attribute. I think this situation in f2023 is a little different because the actual argument might not be allocatable, so the argument association mechanism must be able to tell the difference. A normal subroutine does not have that flexibility. ---
**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\ **Post date:** [August 10, 2024, 5:54pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/7 "2024-08-10T17:54:24Z")
> [@Machalot](#): > > Under the hood does it make sense though? My understanding is that these would be passed by reference, so passing an unallocated variable as an argument has no meaning. Would you require the compiler to identify such a case and implicitly allocate it before passing? But if it’s allocated before passing, how would the compiler ensure the allocation conforms with what the called function needs? OPEN is a Fortran statement - not a function or subroutine. The compiler can do whatever it wants to correctly implement the statement, without being bound to normal calling sequences. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 11, 2024, 3:00am UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/8 "2024-08-11T03:00:22Z")
> [@wspector](#): > > The compiler can do whatever it wants to correctly implement the statement, without being bound to normal calling sequences. I agree that such things are possible, and there are numerous examples of this already in the language, but is this something that we programmers should be encouraging? If some feature is useful for the language semantics, then it is very likely to be useful for programmers too. And the contrapositive is that if something is forbidden for programmers, then maybe it should not be encouraged as part of the intrinsic language. ---
**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")
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? ---
**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\ **Post date:** [August 11, 2024, 6:39pm UTC](https://fortran-lang.discourse.group/t/allow-newunit-to-allocate-an-integer-variable/8451/10 "2024-08-11T18:39:59Z")
> [@Beliavsky](#): > > 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? I did write up such a proposal for this as a F202Y work item, but the committee did not feel this was a good approach, and that the use of `mold` arguments was generally sufficient.