Introduce "auto"

[certik]

Introduced by @pklausler at https://github.com/j3-fortran/fortran_proposals/issues/40#issuecomment-553587810:

Golang has var := expr; which declares var to have the type of the value of expr, which is also assigned to it. The fact that an initializing declaration must necessarily have an expr does make the explicit type somewhat redundant on the statement. So I suggest AUTO :: a = expr, b = expr, ... and AUTO, POINTER :: p => target, ....

Further examples:

AUTO :: a = expr, b = expr, ...
auto :: x = 3.14159
auto, pointer :: p => t

[certik]

@pklausler, mentioned that auto would not preclude an explicit type (or shape).

How would the syntax work? Maybe like this:

auto, integer :: a = expr, b = expr, ...
auto, real :: x = 3.14159

perhaps also like this:

integer, auto :: a = expr, b = expr, ...
real, auto :: x = 3.14159

So it would act like the init proposal at #40, except that in addition to init, it would also allow to omit the type, and it would get inferred.

[aradi]

I think, having auto at a later stage in Fortran will become important. It is not clear to me, though, how it would handle arrays. Would

 auto, allocatable :: a(:) = some_big_array

work?

As for the second comment, I don't see the use case for specifying the type together with the auto keyword. If it is just in order to avoid explicit saving, then I find it counter intuitive (what is "automatic" in integer, auto :: a = expr?).

[FortranFan]

Features like this really get back to the question: For whom Fortran?

Should the consensus be Fortran is for certain (a limited set?) practitioners doing their computing in a manner (say individual development and/or small/isolated teams and/or much longer timescales than viewed by managers wanting "agile development") such that forcing certain verbosity and redundancy in coding instructions are to be always considered a desired "feature" of the language, then there can be a fair argument to ignore type inference facilities such as with auto.

However if Fortran is to be viewed more broadly as being suitable for large new applications also, even in the scientific and technical computing domains, and where the development may span many large teams with huge number of coders and pressing schedules and so forth, then the language development needs to keep an open mind and consider a 'bigger tent' approach. That is, support those wanting explicit typed declarations (as is the case now) but also allow type inferencing.

Consider for example, the development of a 'modern' process simulator of chemical manufacturing facilities costing $$ billions with extensive handling of massive amounts of data in addition to intensive numerical computations: languages supporting features such as the ones introduced in C++ starting their C++11 revision thru' C++14, C++17, and soon C++20 (including with type inference and auto are going to preferred by majority of the developers because these developers then find it easier to rapidly put together functional codes for a lot of the component and libraries which are both critical and reused extensively across the application. Fortran will suffer in such situations if it remains too rigid and inconsistent (seeks explicit type safety in principle but refuses to let go of implicit typing in practice).

[certik]

@FortranFan I can see both sides and I don't currently know if we should have it or not.

As I posted in #40, I use C++ often, and I do not like the auto keyword for simple types such as integer or float. I use auto for complicated iterators, as that simplifies the code a lot (e.g., in "for auto"). But otherwise whenever I can, I try to list the type explicitly, because it makes the code a lot more readable --- the reader can immediately see the types of everything. With auto everywhere, the code starts looking like Python. And Python, while I like it and have been using for 20 years, I find it much less readable than C++ or Fortran, precisely for the lack of visible types. But Python is the best for quickly prototyping an application. Much better than C++.

More generally, I think auto makes it easier to quickly prototype. For example it would be ideal for LFortran in the Jupyter notebook setting. In production code, on the other hand, I think it makes things harder to read and maintain. So I don't know what the best approach is.

[Leonard-Reuter]

But otherwise whenever I can, I try to list the type explicitly, because it makes the code a lot more readable --- the reader can immediately see the types of everything.

I think I would disagree, that no explicit listing of the type makes the code necessarily much less readable for two reasons:

• With good naming of variables, the type should be obvious from the variable name. i.e. variables ending with _count or _index are integers. Having the type written explicitly is then just redundant information
• Most of the C++ code is nowadays written with powerful IDEs, where you can just hover over a variable to see the type. So if you are not able to deduce the type from the name, there is a fast way to look it up (other than going to some functions definition)

However, there are no powerful native Fortran IDEs out there. I for instance use Clion with the Fortran plugin, which works okayish, but not as good as for C++ (especially the refactoring)

[certik]

@Libavius I think you would agree that with no explicit typing, you need an IDE to help you. We should (and we will) have an IDE for Fortran, for example Flang or LFortran will in the future provide the language server for VSCode.

But there is a beauty of not needing an IDE to write and to read code. That's what I mean by simple.

[Leonard-Reuter]

@certik the prospect of a Fortran IDE sounds really promising =).

I agree, that in many cases, explicit typing improves readability. In addition to the IDE stuff, I wanted to point out, that this is not necessarily always the case and that good naming can (sometimes) make explicit typing redundant.

The option of having an auto keyword would give programmers the freedom to avoid this redundancy, while still using explicit types where they improve the readability.

[klausler]

@Libavius I think you would agree that with no explicit typing, you need an IDE to help you. We should (and we will) have an IDE for Fortran, for example Flang or LFortran will in the future provide the language server for VSCode.

But there is a beauty of not needing an IDE to write and to read code. That's what I mean by simple.

It's not all-or-nothing, IDE or not (I do all my programming with a simple editory). Haskell programmers know the power of type inference and are accustomed to adding explicit type signatures where they improve readability, and avoiding them when they don't, for example. And C++ programmers learn where auto does and does not make sense. The circumstances matter.

[certik]

@klausler I think you are right. As long as we provide guidelines how to use auto, I think it would be very useful.

[everythingfunctional]

My understanding is that one of the biggest powers of auto in C++ is that you get proper static typing of local variables in template instantiation. I think the biggest driver for auto in Fortran will come from the generics efforts. Although typeof and classof may diminish that need.

[klausler]

auto is extremely useful in templatized C++ code to avoid having to explicitly write out complicated type expressions (or to avoid using type aliases), yes. And auto is absolutely essential when declaring things whose types are hidden in the compiler (e.g., lambda as local variables for use as internal functions) or polymorphic (e.g., a lambda like [](const auto &x){...} with a hidden template implementation).

But sometimes it's great to have around just to save some completely redundant verbiage in C++. const auto *p{std::get_if<VerboseButInformativeTypeName>(&u)}; isn't made any more readable if the auto is replaced with the long type name, I think. And that's why I think it would be useful in Fortran today -- when there's an initializer with an obvious type.

[fazedo]

auto is very useful in C++, but I see few situations where it will be well employed in Fortran. Let's see some examples in C++: 1) for (auto x: some_list) do_stuff(); // Fortran does not have range-based loops. 2) auto it = something.begin(); // Fortran does not have support for iterators in a generic programming fashion. 3) auto t0 = get_time(); // auto is cool because I don't care about t0 class. ... some code.. auto t1 = get_time(); auto elapsed_time = t1 - t0; // Again I don't care about which class is that. // But Fortran does not allow declarations in the middle of the code. 4) auto f = [] (double x, int n) -> double {some code}; // Again Fortran... 5) int i = 2; auto j = i; // Not good practice. "Explicit is better than implicit." - Tim Peters auto x = 2.3; // Idem. 6) auto x = f(); // Not common to declare variables and define them on the same line.

auto was introduced in C++11 when generic programming was already well settled down, so it found a plethora of good places to be used, while, in Fortran, I don't see it will be really useful.

I do believe Fortran needs support for generic programming as a scientific computing language, which is supposed to translate algorithms, not just formulas, but for the moment that is not the case.

[everythingfunctional]

In a sense, Fortran already does have something roughly equivalent to auto.

associate(x => some_function()) ! x takes on the type and value of the return from some_function
  ! some code
end associate

[fazedo]

Just in case it helps the discussion, there is an excelent talk by Herb Sutter on CppCon 2014 where he discuss several situations where it is a good practice to employ auto: https://youtu.be/xnqTKD8uD64?t=1703 .