From: Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date: 2012-07-23T23:57:23+09:00
Subject: [ruby-core:46667] Re: [ruby-trunk - Feature #4840] Allow returning from require

Em 23-07-2012 10:12, mame (Yusuke Endoh) escreveu:
> Issue #4840 has been updated by mame (Yusuke Endoh).
>
>
> Rodrigo Rosenfeld Rosas,
>
> At the developer meeting (7/21), Matz was basically positive
> to this proposal, but it turned out that we still need to
> discuss corner cases.
>
>
> Here is a discussion summary.
>
> * Matz said that he will accept "return from toplevel", but
>    that reject "return from class definition".
>
>    return if cond # OK
>    class Foo
>      return if cond # NG
>    end

Totally agree.

> * "return from toplevel" should always discard the argument.

You mean "return something", right? I agree. Maybe we could even issue 
an exception if anything other than just "return" is used.

> * What's happen if it returns from the start script (the given
>    script to interpreter as a cmdline)?
>
>    - The argument should be discarded; it does NOT affect the
>      process termination status code
>
>    - The same as "exit", but cannot rescue SystemExit

Agreed. Specifically "return" should be equivalent to "exit 0", right? 
And "return -1" (or any other value, including 0) shouldn't be allowed 
in my opinion, raising an exception, in which case the return value 
wouldn't be 0 obviously :)

> * What's happen in the following corner cases?
>
>    - eval("return") in toplevel

I'd vote for just abandoning any subsequent code in the eval and nothing 
else. Maybe for that case "return" could use the arguments for the 
result of "eval".

>    - proc { return }.call in toplevel

If it is the main program, "exit" would be the equivalent. Otherwise, no 
code would be interpreted after the "call" call.

I don't understand what makes this so special.

> * Matz prefered "return" to "a special exception that require
>    and load rescue",
>
>    - though some people (including ko1) prefered the latter.

I'm okay with raising an exception that would be rescued by require, 
require_relative and load.

Actually I guess this is the simpler approach and it fulfills all the 
real use cases I could think of in this moment.