# Proposal: Add optional arguments to savetxt
**URL:** https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587
**Category:** stdlib
**Created:** [January 2, 2026, 7:53pm UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587 "2026-01-02T19:53:52Z")
**Posts on this page:** 7
**Page:** 2
### Author:  [@fiolj](https://fortran-lang.discourse.group/u/fiolj)
#### Post date: [February 24, 2026, 2:55am UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/21 "2026-02-24T02:55:31Z")
Thanks for the thoughtful comments.
The idea of `savetxt()` (at least for me) is to be a convenience function. After all it is not difficult to write a 2D array to a file. In the use cases I could think of, it would be used for human reading, postprocessing, printing, plotting, etc, rather than rereading by the same program.
In principle, the idea was to somewhat mimic the equivalent function of Python’s Numpy, but we should take into account that they are different languages and the use should be slightly different.
The use of the two versions: `savetxt(filename, array)` and `savetxt(unit, array)` were thought to be complementary. I think some of the comments also point in that direction. I would agree to keep the latter version (`unit`) simple and writing to the “current position” of the file without modifying the position (that would be responsibility of the calling routine). In that case we would have two different signatures:
`savetxt(filename, array, .., comments, append)`
`savetxt(unit, array, .., comments)`
I agree that consistency is important and thus the different options should be explicitly stated in the documentation.
Also, I think it could be a good idea to add the options `asynchronous`|`decimal`|`encoding`|`round`, may be later. For now I would keep it simple, while they could still be used with the `unit` option.
---
### Author:  [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)
#### Post date: [February 24, 2026, 3:55am UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/22 "2026-02-24T03:55:16Z")
My mention of the `asynchronous|decimal|encoding|round|...` arguments of the `open` statement was intended in the other direction (i.e., NOT to add those, since that’s akin to reinventing the wheel).
And the `append` argument for the `savetxt(filename, ...)` version should be ignored if the file is already open, so it’s worth mentioning it in the documentation.
---
### Author:  [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)
#### Post date: [February 24, 2026, 7:45am UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/23 "2026-02-24T07:45:14Z")
> [@fiolj](#):
>
> The idea of `savetxt()` (at least for me) is to be a convenience function. After all it is not difficult to write a 2D array to a file. In the use cases I could think of, it would be used for human reading, postprocessing, printing, plotting, etc, rather than rereading by the same program.
While I agree with the principle, in practice, once a workflow is used, it tends to stay. I’m already aware of many workflows which read and write on such ASCII files simply because the information was already available, or because APIs from other libraries enabled it as the quickest option, etc and so it is kept as an exchange format, even for automated workflows. So I would be very careful about the use of this hypothesis to constrain the design of the API and its internal logic.
---
### Author:  [@fiolj](https://fortran-lang.discourse.group/u/fiolj)
#### Post date: [February 24, 2026, 12:12pm UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/24 "2026-02-24T12:12:10Z")
> [@jwmwalrus](#):
>
> And the `append` argument for the `savetxt(filename, ...)` version should be ignored if the file is already open, so it’s worth mentioning it in the documentation.
I don’t understand. The routine would open and close the file `filename`. Thus I would expect an (either compilation or runtime) error if we pass a file that is already open.
---
### Author:  [@jwmwalrus](https://fortran-lang.discourse.group/u/jwmwalrus)
#### Post date: [February 24, 2026, 12:43pm UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/25 "2026-02-24T12:43:37Z")
> [@fiolj](#):
>
> would expect an (either compilation or runtime) error if we pass a file that is already open.
Not really… or it depends on whether the compiler vendor bothered to implement the feature.
As of [Fortran 2018 (The new features in Fortran 2018, PDF)](https://wg5-fortran.org/N2151-N2200/ISO-IECJTC1-SC22-WG5_N2161_The_New_Features_of_Fortran_2018.pdf), you can issue an `open` statement for a file that’s already open, using a different unit number.
So, the sensible behavior for `savetxt(filename, ...)` would be to first inquire if the file is open. If it is, it should then inquire for a unit number, and behave as the `savetxt(unit, ...)` version, hence my suggestion of ignoring the `append` argument, to not incur in a possible data loss.
---
### Author:  [@fiolj](https://fortran-lang.discourse.group/u/fiolj)
#### Post date: [February 24, 2026, 1:06pm UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/26 "2026-02-24T13:06:51Z")
Oh! I’ve read in the book by Metcalf, Reid and Cohen “incorporating fortran 2018” (Modern Fortran explained, 2018) that:
> A file already connected to one unit must not be specified for connection to another unit.
I missed the section on the article where the prohibition was removed.
Thanks, I will implement your suggestion, that is independent of the compiler behavior concerning opening an already opened file
---
### Author:  [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)
#### Post date: [February 24, 2026, 8:31pm UTC](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587/28 "2026-02-24T20:31:27Z")
> [@fiolj](#):
>
> Thus I would expect an (either compilation or runtime) error if we pass a file that is already open.
The `open` statement in fortran does lots of stuff. The obvious is that it opens a file for the first time and connects a unit number to that file. But the `open` statement can also modify the characteristics of a file that is already open. I gave an example of this above with `open(unit,position='append')`. That statement operates on a file that is already open and already has a connected unit number and modifies its position. You can also rewind a connected file with the open statement (i.e. instead of using a `rewind` statement). The items in an open statement that apply to existing connections are called “changeable modes” in the standard. They include such things as `blank=`, `decimal=`, `delim=`, `leading_zero=`, `pad=`, `round=`, and `sign=`. When combined with the `inquire` statement, you can query for the current value, temporarily change it to process some i/o operations, and then change it back to its original value.
[Previous page](https://fortran-lang.discourse.group/t/proposal-add-optional-arguments-to-savetxt/10587.md?page=1)