Additional intent types: scratch, any, none

[Jellby]

intent(scratch): Some dummy arguments are provided only as a "scratch space", the value on entry doesn't matter, and on output they could be forgotten/overwritten. Formally they are intent(out), but it could be clearer to the reader/programmer, and the compiler could possible perform some extra optimization, if something like intent(scratch) were available. I find mentions to this online but no record to whether (or why) this was rejected.

intent(any): A dummy argument could be intent(in) in some circumstances and intent(out) or intent(inout) in others, for example depending on the value of another argument. Specifying this argument as intent(inout) has the disadvantage of disallowing passing constants values. The only solution is to not specify any intent. intent(any) (equivalent to no intent) would give a more specific signal to reader/user that the behavior of the argument varies, and a constant value is allowed in some cases. I'm not saying this is a good coding practice, but at least it allows making bad code a little bit more explicit.

intent(none): Just adding this for completeness. This would signal an argument that is unused. Compilers would not complain about unused intent(none) arguments, and would instead give an error if such an argument is ever used. Unused arguments may be useful when a procedure must comply to some specific calling sequence, although in that case they'd probably want to comply to the full interface, including intents, so this becomes less useful.

[gklimowicz]

I'm not sure I understand why these are needed. Every feature proposed has to have sufficient use to be able to justify the cost of adding it to the language and all implementations. None of these seems compelling to me.

Scratch space can be handled with local variables internal to the procedure. Or, if for reasons you need the caller to provide it, just comment it as such.

intent(any) is really just intent(inout)' but with the notion that it might or might not be snet on entry, or might or might not be set in the subprogram. One should read intent(inout) as intent(in) or intent(out) or both.

As the standard says, "an INTENT (INOUT) dummy argument is suitable for use both to receive data from and to return data to the invoking scoping unit." It doesn't require that it be both. Again, this is what comments neem to be for.

intent(none)? How about just not have the dummy parameter in the first place?

I would be interested to hear where the need for these comes up in real programming situations that would justify the expense of adding them to the language.

[certik]

I think these are interesting ideas, that would be easy to prototype in a compiler and we should test it out, and see if it is worth it adding to the language.

@gklimowicz, the intent(any) is not equivalent to intent(inout). The difference is that with intent(inout) you cannot call the function with a constant value like this f(5), but with intent(any) you could.

[gklimowicz]

Ick. :-)

[Jellby]

I'm not sure I understand why these are needed.

They are not needed, but I think they could be useful. I'm pretty sure my "modernized" legacy code would be clearer with those.

Scratch space can be handled with local variables internal to the procedure. Or, if for reasons you need the caller to provide it, just comment it as such.

The idea behind intent(scratch) is that (a) it is already a "comment", and (b) it might allow the compiler to apply some optimization if it knows that the final value won't (cannot) be used by the caller.

intent(none)? How about just not have the dummy parameter in the first place?

Sometimes you need to have the argument, like when several procedures must share the same signature (and optional may not be an option).