# Pass a scalar actual argument into an array dummy argument

**URL:** <https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100>\
**Category:** Language enhancement\
**Created:** [September 15, 2026, 12:23am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100 "2026-09-15T00:23:13Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\
**Post date:** [September 15, 2026, 12:23am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/1 "2026-09-15T00:23:13Z")

</div>

I know it’s non-standard pass a scalar variable into a procedure argument where an array is expected, as discussed in other threads on this site. (But it is acceptable to do the reverse, to pass a single array element into a scalar argument.)

This limitation requires developers to make a special overload procedure (generic interface) to handle the scalar case. Here’s an example of what I had to do in some legacy code when I recently updated compiler versions from gfortran 7 to 10+, because some non-standard code that was previously compiling (either unchecked or by extension) now triggers a compile error for this very reason.

```fortran
      call inread(iunit, 5, array_variable) ! read 5 values and store in array elements 1-5
      call inread(iunit, 1, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
      call inread(iunit, 1, scalar_variable) ! ERROR: rank mismatch with gcc 10+

```

Here’s a representation of `inread`’s interface, where `val` is an array:

```fortran
      subroutine inread(iunit,nvars,val)
         implicit none
         integer iunit
         integer nvars
         double precision val(nvars)
      ...

```

So I had to make a generic interface just to handle the scalar case by just copying the scalar in and out of a 1-element array:

```fortran
      interface inread
          module procedure inread_array
          module procedure inread_scalar
      end interface inread

contains
      subroutine inread_array(iunit,nvars,val)
          ...
      end subroutine inread_array

      subroutine inread_scalar(iunit,nvars,valout)
         implicit none
         integer iunit
         integer nvars ! must be 1
         double precision val(nvars), valout

         call inread_array(iunit,nvars,val)
         valout = val(1) ! reassign the array element to the scalar output variable
      end subroutine inread_scalar

```

Would it be possible with explicit interfaces for the compiler to simply treat a scalar actual argument as an assumed-size array of size 1 and the proper rank to match the dummy argument?

---

<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:** [September 15, 2026, 12:54am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/2 "2026-09-15T00:54:28Z")

</div>

If the scalar variable were `intent(in)`, you could have gotten away with,

```fortran
call inread(iunit, 1, [scalar_variable])

```

If `intent(inout)` one solution might have been, to promote the scalar to a single-element array,

```fortran
double precision scalar_variable(1) ! now an array

```

Sometimes you can get away with this with the array semantics. If that doesn’t work, it’s possible to get a scalar with `associate`:

```auto
program test
double precision scalar_variable(1) ! now an array
scalar_variable = 99
associate(scalar => scalar_variable(1)) 
   scalar = 42
end associate
print *, scalar_variable ! prints 42.0
end program

```

I tested this works as expected with gfortran 10. One questionable aspect is you have the same array (element) appearing under two different names. 🤷‍♂️

If you don’t like `associate`, then my last idea (ignoring the preprocessor…) would be search and replace `scalar_variable` with `scalar_variable(1)` in the expressions were it **must** be a scalar. You’d be making no changes in the procedure, only on the caller side.

---

<div class="post-metadata">

**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\
**Post date:** [September 15, 2026, 1:14am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/3 "2026-09-15T01:14:47Z")

</div>

> [@ivanpribec](#):
>
> If `intent(inout)` one solution might have been, to promote the scalar to a single-element array,
> 
> ```auto
> double precision scalar_variable(1) ! now an array
> 
> ```
> 
> …  
> If you don’t like `associate`, then my last idea (ignoring the preprocessor…) would be search and replace `scalar_variable` with `scalar_variable(1)` in the expressions were it **must** be a scalar. You’d be making no changes in the procedure, only on the caller side.

Unfortunately this would be much worse than the annoyance of creating this thin generic interface. This `inread` subroutine is invoked thousands of times to read dozens of data files, with a mix of scalars and arrays under no particular order. To find every instance it is called with a scalar variable, declare a throwaway 1-element array, replace the argument, and reassign the value, would be daunting compared to the new dozen lines of the generic interface.

I’m not unhappy with this generic interface solution, but it occurred to me that it might be unnecessary if the language could be updated to allow scalars in this context. Matlab generally does allow scalars and arrays to be used interchangeable in function arguments (perhaps because everything is inherently an array?).

---

<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:** [September 15, 2026, 1:39am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/4 "2026-09-15T01:39:02Z")

</div>

At least temporarily, moving forward with `-fallow-argument-mismatch` could be an option. But in the long run it is just more technical debt.

One more possiblity would be using an **assumed rank** argument ([Compiler Explorer](https://godbolt.org/z/37Yxs9xWd)); it works with gfortran 10:

```fortran
module foo
implicit none
contains
    subroutine inread(iunit,nvars,val)
         implicit none
         integer iunit
         integer nvars
         double precision, contiguous :: val(..)
        print *, "iunit = ", iunit
        print *, "nvars = ", nvars
        select rank(val)
        rank(0)
            if (nvars /= 1) error stop "expected a scalar"
            print *, "val is scalar"
        rank(1)
            if (size(val) < nvars) error stop "size mismatch"
           print *, "val is a 1-d array"
        rank default
            error stop
        end select
     end subroutine
end module

program test
use, intrinsic :: iso_fortran_env, only: iunit => input_unit
use foo, only: inread
implicit none

real(kind(1.0d0)) :: array_variable(6)
real(kind(1.0d0)) :: scalar_variable

call inread(iunit, 5, array_variable) ! read 5 values and store in array elements 1-5
call inread(iunit, 1, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
call inread(iunit, 1, scalar_variable)   

end program

```

The disadvantage compare to your generic interface is the rank is resolved at runtime. It also needs error checking, but so would `inread_scalar`:

```fortran
      subroutine inread_scalar(iunit,nvars,defin,valout)
         implicit none
         integer iunit
         integer nvars ! must be 1
         character*(*) defin(nvars)
         double precision val(nvars), valout
         if (nvars /= 1) error stop "inread: wrong value for nvars"
         ! ...
      end subroutine inread_scalar

```

Edit: corrected generic to assumed rank.

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [September 15, 2026, 1:40am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/5 "2026-09-15T01:40:21Z")

</div>

Would assumed rank work in this case? I’ve never used it so I don’t really know what the limitations on assumed rank are.

---

<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:** [September 15, 2026, 2:06am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/6 "2026-09-15T02:06:08Z")

</div>

> [@Machalot](#):
>
> This `inread` subroutine is invoked thousands of times to read dozens of data files, with a mix of scalars and arrays under no particular order. To find every instance it is called with a scalar variable, declare a throwaway 1-element array, replace the argument, and reassign the value, would be daunting compared to the new dozen lines of the generic interface.

Assuming no line breaks or other surprises, I reckon this particular case could be handled with a regex:

```txt
$ cat inread.f90
      call inread(iunit, 5, array_variable) ! read 5 values and store in array elements 1-5
      call inread(iunit, 1, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
      call inread(iunit, 1, scalar_variable) ! ERROR: rank mismatch with gcc 10+
$ grep -inE 'call\s+inread\s*\([^,]+,\s*1\s*,' inread.f90
2: call inread(iunit, 1, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
3: call inread(iunit, 1, scalar_variable) ! ERROR: rank mismatch with gcc 10+

```

With some search and replace logic it could even try to substitute with a scalar interface (without the `nvars`),

```auto
      subroutine inread_scalar(iunit,defin,valout)
         implicit none
         integer iunit
         character(len=*) defin
         double precision valout
         ! local variables 
         double precision val(1)
         call inread_array(iunit,1,[defin],val)
         valout = val(1)
      end subroutine inread_scalar

```

An LLM should be quite capable of generating a script to do the replacement; here is just a quick test I did,

```auto
# fix_inread.py
import re, sys, difflib

pat = re.compile(r'\bcall\s+inread\s*\(\s*([^,()]+)\s*,\s*1\s*,\s*', re.IGNORECASE)

for fname in sys.argv[1:]:
    with open(fname) as f:
        old = f.read().splitlines()
    new = [pat.sub(r'call inread(\1, ', line) for line in old]
    if new != old:
        diff = difflib.unified_diff(old, new, fromfile=fname, tofile=fname, lineterm='')
        print('\n'.join(diff))

```

Running this with `python3 fix_inread.py *.f90 > inread.patch`, produces,

```auto
--- inread.f90
+++ inread.f90
@@ -1,3 +1,3 @@
       call inread(iunit, 5, array_variable) ! read 5 values and store in array elements 1-5
- call inread(iunit, 1, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
- call inread(iunit, 1, scalar_variable) ! ERROR: rank mismatch with gcc 10+
+ call inread(iunit, array_variable(6)) ! read 1 value and store in array element 6 by sequence association
+ call inread(iunit, scalar_variable) ! ERROR: rank mismatch with gcc 10+

```

The LLM can iterate on the replacement script and patch as long as it needs to verify every scalar case is replaced correctly.

---

<div class="post-metadata">

**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\
**Post date:** [September 15, 2026, 2:43am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/7 "2026-09-15T02:43:10Z")

</div>

I created a small test program for assumed rank based on the description of assumed rank in the 2018 version of MFE and it appears to work with ifx 2025.3 and gfortran-15. Here is the code

```auto
Program testar

  USE ISO_FORTRAN_ENV, WP=>REAL64, stdin=>INPUT_UNIT

  Implicit NONE
  Real(WP) :: scalar
  Real(WP) :: array(5)

  Call inread(stdin, 1, scalar)
  Call inread(stdin, 5, array)

  Print *,' scalar = ', scalar
  Print *,' array = ', array(1:5)

  STOP

Contains

  Subroutine inread(iunit, nvars, var)

    Integer, Intent(IN) :: iunit, nvars
    Real(WP), Intent(INOUT) :: var(..)

    Select Rank(var)

      Rank(0)

        If (nvars/= 1) Then
          Print *, ' nvars /= 1 and var is a scalar'
          var = 0.0_WP
        Else
           Read(iunit,*) var
        End If

       Rank(1)

         Read(iunit,*) var(1:nvars)

       Rank Default

         Print *,' Rank > 1'

    End Select

  End Subroutine inread

End Program testar

```

The input file was  
5.0  
1.0 2.0 3.0 4.0 5.0

The biggest problem I see with using assumed rank for this case is that the rank selection is done at run time so if inread is called thousands of time there might be a considerable performance penalty.

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [September 15, 2026, 3:03am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/8 "2026-09-15T03:03:05Z")

</div>

> [@Machalot](#):
>
> […] but it occurred to me that it might be unnecessary if the language could be updated to allow scalars in this context.

I doubt that such a change could be done within any timeframe where it would be useful (i.e. portable across a wide range of compilers).

I think the language was written this way because some compilers would pass scalar arguments by value through registers (essentially copy-in/copy-out through registers) while array arguments were passed by address in a stack frame. However, I’m unsure how the array element argument to scalar association occurred in this case. Does anyone know more about this history of the language?

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [September 15, 2026, 8:30am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/9 "2026-09-15T08:30:06Z")

</div>

> [@Machalot](#):
>
> So I had to make a generic interface just to handle the scalar case

This is by far the best move IMO, unless you have dozens of procedures like that. The original procedure is not modified, and with a few additional lines you solve all the calls at once.

And because generic interfaces (for compile-time resolution) and assumed rank (for run-time resulution) features exist, there’s very little chance that such a change (which weakens the argument conformance) be approved.

---

<div class="post-metadata">

**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\
**Post date:** [September 15, 2026, 9:34am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/10 "2026-09-15T09:34:56Z")

</div>

The use of a scalar in this way was allowed by most compilers prior to F90.  
It is typically used in “F77 wrappers”, where the argument merely provides a memory address.  
Since F90, compilers have adopted a greater adherance to the standard, but most still provide an exception via -fallow-argument-mismatch.  
There are standard conforming approaches as discussed above, but it is easier to use the compiler extension and document why you need it.  
For me, the use of memory addresses in this way is much more robust that the use of pointers or associate that has been introduced into the language.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [September 15, 2026, 9:53am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/11 "2026-09-15T09:53:45Z")

</div>

> [@JohnCampbell](#):
>
> The use of a scalar in this way was allowed by most compilers prior to F90.

It was not really allowed, it’s rather that there were no interfaces and consequently the compilers could not enforce the argument conformance. BTW you can still do that: a dangling external procedure (not in a module and without an interface block in the caller) in a separate file, and compilers won’t complain about rank mismatch.

> [@JohnCampbell](#):
>
> For me, the use of memory addresses in this way is much more robust that the use of pointers or associate that has been introduced into the language.

But at the same time (if using -fallow-argument-mismatch) you are weakening the safety all the calls in the file compiled with this switch. So, I wouldn’t say it is “robust”

---

<div class="post-metadata">

**Author:** ![cmaapic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/cmaapic/32/659_2.png) [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)\
**Post date:** [September 15, 2026, 11:03am UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/12 "2026-09-15T11:03:17Z")

</div>

> [@PierU](#):
>
> It was not really allowed, it’s rather that there were no interfaces and consequently the compilers could not enforce the argument conformance.

If I recall correctly some compilers did catch this (issue a warning) when doing a complete recompile of the whole code. The main Fortran 77 compiler I worked with was the CDC compiler.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [September 15, 2026, 3:47pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/13 "2026-09-15T15:47:17Z")

</div>

> [@cmaapic](#):
>
> If I recall correctly some compilers did catch this (issue a warning) when doing a complete recompile of the whole code. The main Fortran 77 compiler I worked with was the CDC compiler.

This is indeed easy when both the caller and the callee are in the same source file. If they are not this is still possible but a bit more difficult…

---

<div class="post-metadata">

**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\
**Post date:** [September 15, 2026, 4:39pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/14 "2026-09-15T16:39:16Z")

</div>

> [@rwmsu](#):
>
> I created a small test program for assumed rank based on the description of assumed rank in the 2018 version of MFE and it appears to work with ifx 2025.3 and gfortran-15.

It now works with LFortran also (as of today:):

```console
$ lfortran a.f90 < input
 scalar = 5.0000000000000000
 array = 1.0000000000000000 2.0000000000000000 3.0000000000000000 4.0000000000000000 5.0000000000000000
STOP

```

> [@rwmsu](#):
>
> The biggest problem I see with using assumed rank for this case is that the rank selection is done at run time so if inread is called thousands of time there might be a considerable performance penalty.

Yes, it is indeed runtime.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [September 15, 2026, 4:39pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/15 "2026-09-15T16:39:38Z")

</div>

This comes up a lot and is either the number one or number two problem encountered in modernizing old code in my opinion as every old machine I used allowed it and most codes used it but it never made it into the standard and there had been no progress in getting it made standard. For an example  
of a module that allows this see [GitHub - urbanjost/M\_flatten: return a rank one array pointer to a scalar or array of any rank · GitHub](https://github.com/urbanjost/M_flatten). I thing changing everything to an array, passing into intent(in) as an array expression, keeping the code old-style without an interface and many other of the methods have been mentioned except one of the most commonly used and sometimes the easiest to implement – use EQUIVALENCE and give it both a scalar and array or array element name. Use a naming convention to easily identify the alternate name. Some of the techniques discussed as well as generic interfaces become quite complicated when many arguments are used as both scalar and array elements whereas the EQUIVALENCE method and the M\_flatten module scale linearly. In my experience changing everything to an array works well. The reason a lot of these calls exist in the first place is that Fortran did not allow arrays with a dimension of one. Not sure why, but the fact that passing a scalar worked on practically everyone and that flaw in early Fortran it was natural to just pass the scalar. Anything that works empirically becomes a feature given enough time, as everyone does not read the standard to see if every line conforms. So if the compiler did not complain and “every” compiler accepted the syntax it became a de-facto standard and appears in the majority of older codes. The “natural” solution to create generic interfaces falls apart when there are dozens of arguments. Oh, another approach is to create user types and just pass those and get rid of those 20-argument procedure calls. That does not directly address this but in the process of changing to user types you can clean up the scalar/array problem and end up with generally much easier code to read. As much hatred as equivalence seems to get (probably right behind GOTO) it is efficient and unlikely to be going away in any Fortran compiler that wants a general audience.

---

<div class="post-metadata">

**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\
**Post date:** [September 15, 2026, 4:44pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/16 "2026-09-15T16:44:47Z")

</div>

> [@RonShepard](#):
>
> I doubt that such a change could be done within any timeframe where it would be useful (i.e. portable across a wide range of compilers).

Can you clarify? Don’t all language changes take some time before they are available and useful? Is this one particularly hard?

> [@PierU](#):
>
> This is by far the best move IMO, unless you have dozens of procedures like that.

Unfortunately I do have over a dozen such procedures for other purposes (reading other data formats, writing output, applying random perturbations to variables, etc.). This would potentially be a large effort, but thankfully with the help of AI coding agents it only took me a few days to migrate them all to new modules and implement generic interfaces.

> [@JohnCampbell](#):
>
> Since F90, compilers have adopted a greater adherance to the standard, but most still provide an exception via -fallow-argument-mismatch.  
> There are standard conforming approaches as discussed above, but it is easier to use the compiler extension and document why you need it.

At first I applied the compiler option, but actually found it was worth the effort to make the generic interface, because in the process it allowed me to find and fix a lot of very old bugs.

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [September 15, 2026, 6:22pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/17 "2026-09-15T18:22:31Z")

</div>

> [@Machalot](#):
>
> Can you clarify? Don’t all language changes take some time before they are available and useful? Is this one particularly hard?

i was thinking of such features as parameterized data types. That feature also doesn’t look hard to someone like me who does not write compilers, but the feature was introduced to the language now over 20 years ago and it still does not work fully on all of the popular fortran compilers. Considering all of the possible complications that might arise by enforcing this new argument association, a similar kind of time lag might also occur for this proposed feature.

This might be similar to the implicit save feature for fortran. That feature was introduced into the language to bring previously nonconforming code into compliance, but it had/has also several adverse unintended consequences.

> [@cmaapic](#):
>
> If I recall correctly some compilers did catch this (issue a warning) when doing a complete recompile of the whole code.

Yes, same for me. Also, if your code had multiple calls to the same external function, some with scalar arguments and some with array arguments, then f77 era compilers could also detect that possible error.

---

<div class="post-metadata">

**Author:** ![Machalot](https://avatars.discourse-cdn.com/v4/letter/m/ebca7d/32.png) [@Machalot](https://fortran-lang.discourse.group/u/Machalot)\
**Post date:** [September 15, 2026, 7:28pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/18 "2026-09-15T19:28:19Z")

</div>

> [@PierU](#):
>
> And because generic interfaces (for compile-time resolution) and assumed rank (for run-time resulution) features exist, there’s very little chance that such a change (which weakens the argument conformance) be approved.

We’re all concerned here about the popularity and long term prospects of Fortran. Among all the languages I could use for my next project (or continue to use to extend my legacy project), is it _nice_ to use Fortran? If I have to build this claptrap of a generic interface wrapper for a scalar to use the same subroutine that I can easily use with an array or a single array element\*, that makes the language less _nice_, and more _annoying_ to use. Especially when other languages can easily do it.

\* `elemental` functions can do this, right? Or is this apples vs oranges?

---

<div class="post-metadata">

**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\
**Post date:** [September 15, 2026, 7:56pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/19 "2026-09-15T19:56:57Z")

</div>

> [@Machalot](#):
>
> If I have to build this claptrap of a generic interface wrapper for a scalar to use the same subroutine that I can easily use with an array or a single array element\*, that makes the language less _nice_, and more _annoying_ to use. Especially when other languages can easily do it.

That is how assumed rank came about in F2018. One poster child was the MPI library. But it has broader applicability.

> [@](#):
>
> \* `elemental` functions can do this, right? Or is this apples vs oranges?

To a large extent, apples vs oranges.

---

<div class="post-metadata">

**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\
**Post date:** [September 15, 2026, 8:01pm UTC](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100/20 "2026-09-15T20:01:27Z")

</div>

> [@Machalot](#):
>
> If I have to build this claptrap of a generic interface wrapper for a scalar to use the same subroutine that I can easily use with an array or a single array element\*, that makes the language less _nice_, and more _annoying_ to use. Especially when other languages can easily do it.

I get that, but in the present case allowing a dummy scalar for the actual array would mean weakening the TKR rule for argument conformance, leaving more room to argument errors in the calls.

In C or similar this is less a problem because the call with a scalar does require the “&” operator, so there’s no risk of inappropriate call.

Note : there’s a not very elegant and maybe not standard conforming solution by defining some functions that turn scalars into rank 1 pointers:

```auto
function scalar2array(s) result(p)
use iso_c_binding
real, intent(in), pointer:: s
real, pointer :: p(:)
call c_f_pointer( c_loc(s), p, [1] )
end function

```

Then you can use `scalar2array(s)` in the calls to your functions that require arrays. Not sure it more efficient that the assumed-rank solution, though.

> [@Machalot](#):
>
> \* `elemental` functions can do this, right? Or is this apples vs oranges?

Yes they possibly can. But it fully depends on the specific case you are dealing with.

* * *

EDIT: the above solution looks standard conforming:  
 ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/2/201f8cf9046b9134dfacb7f439f834287690a25e.png)

> Case (ii):  
> If the value of CPTR is the result of a reference to C\_LOC with a noninter-  
> operable effective argument X, FPTR shall be a nonpolymorphic pointer with  
> the same type and type parameters as X. […]. If X is scalar, FPTR becomes  
> pointer associated with X; […]

[Next page](https://fortran-lang.discourse.group/t/pass-a-scalar-actual-argument-into-an-array-dummy-argument/11100.md?page=2)