Notices by Tom Hayward (hattom@mastodon.social)

@ArneBab @jeffscience I really don't remember for sure. But I think it wasn't quite that, but rather that it's not a normal mathematical operation; traditional operators have been words. I don't know where I read the discussion, but it was a long time ago.

@ArneBab iirc, @jeffscience wrote something about it before -- committee argued against it for some strange reason (because it's not pronounceable??) and shot down the proposal.

Thanks for the link, I'll take a look!

@ArneBab we have all 3 (real function X; function X + real::X; function X result(Y) + real::Y) in our production code.

I only use the result option if the function name is quite long; or the function name and the return value name are not logical enough [e.g.: function get_integral_from_shape(shape) result(integral)].

Definitely don't want to be writing code with lines like:
get_integral_from_shape_cubic = get_integral_from_shape_cubic + func(get_integral_from_shape_cubic)

Oh... I wish "+="

@ArneBab while I'm at it with unnecessary comments, you don't *have* to set the return value of a function to a variable of the same name, but if you don't want to, you need to be explicit about what the name of the result is called.

function myfunc result(ans)
real :: ans
ans = 3.0
end function

@ArneBab lots of good stuff in there!

"Alternative: Declare the return type of a function inside the function" -- this is what I do for any function which returns anything other than a scalar of one of the simple built-in types.

The part about accumulation is quite subtle -- variables can have a property "save" which makes them persistent across calls.
Any initialisation in the declaration line implicitly makes them "save", which is often counter intuitive.
Reminds me of python's: def a(b=[]):

@ColinTheMathmo What's the diagonal line?