Project

General

Profile

Bug #11143

it should always be possible to return from an if

Added by bughit (bug hit) over 5 years ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:69150]

Description

irb(main):001:0> def foo; a = if true then return end end
SyntaxError: (irb):1: void value expression

it should not matter that you are not producing a value for the if expression, since you are leaving the method immediately. This should also apply to other jumps.


Related issues

Related to Ruby master - Bug #15932: wrong "void value expression" error for 'next' or 'break' statements inside an 'if' assignmentClosedActions

Updated by nobu (Nobuyoshi Nakada) over 5 years ago

  • Status changed from Open to Rejected

Why do you need such assignment?

#2

Updated by bughit (bug hit) over 5 years ago

Nobuyoshi Nakada wrote:

Why do you need such assignment?

What does my "need" have to do with whether something should be a syntax error or not?

Just about everything in ruby is an expression and all expressions can potentially fail to produce a value (due to some jump: raise, throw, return, etc). That does not make such expressions syntactically invalid (e.g. a = (1; return; 2)), except for the if? Why?

#3

Updated by bughit (bug hit) over 5 years ago

What is the objection to providing some sort explanation when rejecting a bug report?

#4

Updated by nobu (Nobuyoshi Nakada) over 5 years ago

bug hit wrote:

Nobuyoshi Nakada wrote:

Why do you need such assignment?

What does my "need" have to do with whether something should be a syntax error or not?

I wanted to know the use-case.

Just about everything in ruby is an expression and all expressions can potentially fail to produce a value (due to some jump: raise, throw, return, etc). That does not make such expressions syntactically invalid (e.g. a = (1; return; 2)), except for the if? Why?

Thank you, it's a bug.
That return should be invalid too.

#5

Updated by nobu (Nobuyoshi Nakada) over 5 years ago

  • Status changed from Rejected to Open
#6

Updated by bughit (bug hit) over 5 years ago

Nobuyoshi Nakada wrote:

Just about everything in ruby is an expression and all expressions can potentially fail to produce a value (due to some jump: raise, throw, return, etc). That does not make such expressions syntactically invalid (e.g. a = (1; return; 2)), except for the if? Why?

Thank you, it's a bug.
That return should be invalid too.

There is nothing special about return, there are other jumps (return, break, next, redo, retry, throw, raise)

For your proposal to make sense, you would have to detect every possible jump in every possible expression whose value is not discarded, and produce a syntax error. This is crazy. You still have not stated why that's a good idea. AFAICT there is nothing wrong and in many cases useful to be able to jump out of an expression when conditions warrant, especially because in ruby just about everything is an expression.

#7

Updated by bughit (bug hit) over 5 years ago

bug hit wrote:

Nobuyoshi Nakada wrote:

Just about everything in ruby is an expression and all expressions can potentially fail to produce a value (due to some jump: raise, throw, return, etc). That does not make such expressions syntactically invalid (e.g. a = (1; return; 2)), except for the if? Why?

Thank you, it's a bug.
That return should be invalid too.

There is nothing special about return, there are other jumps (return, break, next, redo, retry, throw, raise)

For your proposal to make sense, you would have to detect every possible jump in every possible expression whose value is not discarded, and produce a syntax error. This is crazy. You still have not stated why that's a good idea. AFAICT there is nothing wrong and in many cases useful to be able to jump out of an expression when conditions warrant, especially because in ruby just about everything is an expression.

To expand on why this is crazy.

  1. All the jumps (return, break, next, redo, retry, throw, raise) should be treated the same, because they all have the same effect, break out of the expression, preventing it from producing a value
  2. If you forbid jumping out of expressions, you will undoubtedly break a lot of code, and for no good reason.
  3. because if you are in an expression, (e.g. begin/end, if) and certain conditions arise such that it does not make sense to continue the normal flow, jumping out of it by raising or returning (or whatever jump is appropriate) is perfectly reasonable, and it makes zero sense to forbid it, and you have not even tried to justify it.

So the reasonable thing to do is not to expand this restriction, but to lift it entirely.

#8

Updated by jeremyevans0 (Jeremy Evans) over 1 year ago

  • Related to Bug #15932: wrong "void value expression" error for 'next' or 'break' statements inside an 'if' assignment added

Updated by jeremyevans0 (Jeremy Evans) over 1 year ago

  • Status changed from Open to Closed

Updated by marcandre (Marc-Andre Lafortune) 8 months ago

Just got hit by this. Is this difficult to backport to supported versions?

#11

Updated by marcandre (Marc-Andre Lafortune) 8 months ago

  • Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN to 2.5: REQUIRED, 2.6: REQUIRED

Also available in: Atom PDF