void value expressions make no sense

void_value_expressions.rb

-> { a = case when true then return end } # this is allowed
-> { a = if true then return end }        # this is not
-> { a = if true then return; 2 end }     # this is

-> { a = (true && return) } # this is allowed
-> { a = (return && true) } # this is not

-> { a = begin;  return
         rescue; return
         ensure; return
         end }                # this is allowed
-> { a = begin; return; end } # this is not

I know what a void value expression is, I constantly have to work around it in Seeing Is Believing.

I'm sorry; I didn't intend for that to sound condescending! I was just explaining for the benefit of someone reading who might not know.

but then a = if true; else return end should be allowed, because you've finished evaluating the if statement.

You haven't finished evaluating the if statement, just the conditional portion (that's what the cond flag checks; see here). The body of a node must also be evaluated by the parser before it can keep going, and the body here is a return node (NODE_RETURN), so you get the void value expression problem when control reaches line 8818 in parse.y.

Mostly I point this out because it also illustrates the unnecessity of void value expressions

100% agree that they seem unnecessary. I'm not sure why that level of static analysis is done in the parser. This is probably a question for the ruby-lang list.

Your having to go to the implementation to explain it is evidence that there is no clear rule, of course, I'd already experimentally arrived at the same conclusion.

The rule to me is "if you try to assign from an expression whose parser-evaluated value is a node that causes a change in control flow, and you're not in the middle of evaluating a conditional node, then you will get a VVE".

(they could just stop doing that and all known bugs in my gem would go away).

I'm not a SIB user so I haven't studied the code, but that misses one other case where a VVE can be raised -- when a method definition is a VVE. Could that account for some of your bug cases?

I'm definitely curious about why VVEs exist in the parser at all. There's also only three tests for them in RubySpec and none of them cover the case you describe. So they seem to be not very important. Maybe it's worth proposing a patch to ruby-lang?

The real problem is that Ruby is an insane language and you're still using it.

Hello @sdegutis !!
how can you say Ruby is insane language ?

Don't just make unusable comments .

Lets face it, it's an inferior attempt at unnecessary static analysis that leads to incongruent results. this is not to say that it is valueless, I think there may be some very small amount of value. However, I don't think its value exceeds its cost, and I don't think it makes any sense.

You have cleanly nailed it; to my complete surprise, there are some devs out there that still confuse a void-value-expression (an expression with no inherent value) with a void-value-expression-error (an error caused by mixing so-called "value expressions" with "void-expressions").

Interestingly enough, the most basic forms of void-value-expressions are break, next, return and raise, all of which, intuitively, are used to change the natural path of execution in some way. To me, that has been the reason of the dichotomy between value-expressions and void-expressions -- to prevent things like 12 * break or 12 * (return 12).

To a sane mind, a void value expression error is raised only when the value of a void value expression is needed to resume the execution of the program in some way:

• Consider 12 * break: the value for break is needed to calculate the value for 12 * break, and that is where the error occurs.
• Now consider this: break && l() -- the value for break is needed to decide whether l() should execute. this, too, is an error.
• On the other hand, consider 12 && break -- the value for 12 is needed to decide whether we should proceed to executing break -- which makes complete sense to be honest, because, even though we had a break, its value was not needed.

Now consider this: (12 && break) && return. Sanity-wise, the reasoning that supposed to lead us through executing it would be:
* the value for 12 is needed to decide whether break should execute (nothing wrong with that!)
* the value for 12 && break is needed to decide whether return should execute (12 && break has no inherent value -- it's not even nil, it must be thought of as a "compound" void-expression, and at this point a "void-value-expression-error" must be actually raised!)
** BUT IT WON'T **
That to me is nothing but poor and insane implementation of a feature that could have had a slight value.

Ruby as a language is not insane (it's a mere description), but the way its standard implementation behaves makes me run for cover occasionally. tl;dr Checks performed for hunting void-value-expression-errors are half-baked and are, at their best, useless, at least the way they are implemented currently.

Ruby is insane, because is genial!