From: SASADA Koichi <ko1@...>
Date: 2012-07-24T10:37:43+09:00
Subject: [ruby-core:46702] Re: [ruby-trunk - Feature #4840] Allow returning from require

(2012/07/23 23:57), Rodrigo Rosenfeld Rosas wrote:
>> * "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 :)

matz proposed that ignore return argument completely.  matz also said to
avoid mistake, return expression with argument (example: "return foo")
should be syntax error.


>>    - 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.

(1)
  pr = proc{return}
  def foo(pr)
    pr.call # what happen?
  end

(1')
  1.times{
    return
  }

(2)
  # a.rb
  $pr = proc{return}

  # b.rb
  require './a.rb'
  $pr.call # waht happen?

(3)
  begin
    ...
  rescue
    return
  ensure
    return
  end

matz proposed that "accept return on toplevel (not in block, classes, etc)".

>> * 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.

I strongly recommended the exception approach because there are *NO*
difficult corner cases.

However, matz disagreed the exception approach because of "raise
StopLoading is too long".  It is a kind of "name is not good".

-- 
// SASADA Koichi at atdot dot net