I wonder, whether it is just a bug or a parser limitation (I can't guess which ambiguity the space-less version produces, but I could be missing something)?..
mame explained that the behaviour is correct (in the context).
Perhaps the documentation could explain that, because I agree
with zverok at the least initially to assume that there should
not be a difference in behaviour between the two. At the least
I think that it would be better to have this explained in the
documentation as-is, similar to how mame explained that.
I agree that Ruby syntax is very subtle. Ruby's parser is a unspeakable monolith of compromise between human intuition and parser limitation.
Consider the following code:
foo(x, y, z = ary)
It may have two possible interpretations: foo(x, y, (z = ary)) (foo accepts three arguments and the last one is an assignment expression) and foo((x, y, z = ary)) (foo accepts one argument that is a multiple assignment statement). To prevent the second interpretation, only an expression is allowed as an argument. Integer(ENV['FOO']) rescue nil is a statement, so it cannot be written as an argument.
By the way,
A statement can be converted to an expression by surrounding parentheses: (Integer(ENV['FOO']) rescue nil) is an expression. So you can write foo((Integer(ENV['FOO']) rescue nil)).
Ruby allows to omit parentheses of method calls: foo x is considered foo(x). So you can write foo (Integer(ENV['FOO']) rescue nil). Note that the space is required to distinguish from a normal method call foo(x).
This is just my understanding. The source code of the parser says "what it does" but doesn't say "why it does (or doesn't)", so we need to surmise. My guess could be wrong.
Oh, thanks! In fact, that was the piece of understanding I missed trying to catch how space- and spaceless-versions are different from PoW of the interpreter.
The ticket could be closed, I just wanted to clarify things a bit.