io: getfile

[perazz]

This PR is spun off #904 for discussion with #919.

The present option provides a getfile function that has a similar functionality as the existing getline from the stdlib_io module:

stdlib_io

• type(string_type) function getfile(fileName [,err] [,delete]) loads a whole ASCII file into a string_type variable all at once, with option to return a state flag, or to request file deletion (delete=.true.) after loading.

• The file is loaded all at once for maximum computational efficiency.

• The new state_type error handler is optionally used to provide clear error information. Its optional as commonly done in linear algebra routines: if provided, an error message may be returned; if not provided, exceptions trigger an error stop

cc: @jvdp1 @chuckyvt @jalvesz @fortran-lang/stdlib

[jvdp1]

Thank you @perazz. LGTM!
I am not a fan of the Camel case, but it is just a matter of taste.

[chuckyvt]

My suggestion is this is a better fit as a subroutine. I wouldn't expect anyone to use this in line with other operations. Also a subroutine is easier to extend to other data types in the future if desired. (Since the output argument and type is provided)

[perazz]

• make it a subroutine
• character(:), allocatable or string_type output interface

[chuckyvt]

Well, while @perazz is making changes, any chance we could add a "notabs" type option? My organization loves to sprinkle tabs into text files, which often wrecks havoc downstream.

[perazz]

@chuckyvt the string module has a replace_all function that I believe could be a better way to handle that? As we load the whole file at once, there's no way to replace tabs with spaces withouth additional allocations anyway, so it makes sense to call a second function I guess?

[jalvesz]

Thanks @perazz for this contribution. Just a style comment, as @jvdp1 mentioned camel case is not recommended in the stdlib guidelines, actually here https://github.com/fortran-lang/stdlib/blob/HEAD/STYLE_GUIDE.md#variable-and-procedure-naming is mentioned that snake_case should be prefered. If possible, I would suggest applying it to the naming of the procedures get_file instead of getfile and so on.

[perazz]

Thank you for the edits @jalvesz - regarding the function name, I think it would not be a good idea to have get_file but getline. We could do get_file and get_line, at the price of a backward incompatible change. Open to discussion on this.

[jalvesz]

We could do get_file and get_line, at the price of a backward incompatible change. Open to discussion on this.

I would be in favor of this, considering that the interfaces are still tagged as experimental breaking changes are expected (we should document it). My reading here is that since there is no mechanism implemented to check the respect of the style guide, deviations have been introduced. I wonder if something like that could be done?

Out of curiosity I asked chatgpt: https://chatgpt.com/share/67bdeee7-a7dc-800f-bf12-6d9bf8774486 it looks feasible... there are many errors but the raw idea seems to hold, and the key point about "pre-commit" seems to be indeed available, maybe the tooling proposed by Codee could help? https://fortran-lang.discourse.group/t/webinar-enforcing-fortran-coding-guidelines-with-codee/9179

[jvdp1]

would be in favor of this, considering that the interfaces are still tagged as experimental breaking changes are expected (we should document it).

I agree with @jalvesz; As it is in experimental it can still be changed. However, I don't have preferences between getline or get_line.

My reading here is that since there is no mechanism implemented to check the respect of the style guide, deviations have been introduced. I wonder if something like that could be done?

For my private projects in gitlab, I use fprettify to check the formatting. If changes are generated by fprettify, then the rest of the CI/CD does not start.

[perazz]

With two approvals, I will merge this one. Thank you @jvdp1 @jalvesz for the reviews.