[ruby-core:46705] Re: [ruby-trunk - Feature #4840] Allow returning from require

Em 23-07-2012 22:37, SASADA Koichi escreveu:
> (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.

Better yet.

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

I wonder why someone would write code like this in the first place, but 
if someone did he is probably expecting the program to terminate with 
exit if this is the main file. For required files I have no idea what 
someone would expect from code like this. I'd probably raise an 
exception in such situation because it is most likely a logic error that 
could be hard to debug... I know what you mean, should that method "foo" 
be defined or not? What should be its definition? I have no idea because 
code like this simply doesn't make any sense to me.

> (1')
>    1.times{
>      return
>    }

This one I can think of. But something like:

['a', 'b'].each {|item|
   return if defined? item2module(item)
}

This would simply return from the require. I still don't understand why 
this would be so special.

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

Wow! I wouldn't ever think in something like this! Congratulations, 
you're really creative!

Again, why the hell would someone do something like this? I'd just raise 
an error when trying to call $pr because return has no more meaning 
after that file has been already required.

>    # 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)".

I agree, this is way more simple to deal with. Even though I can think 
about someone using an approach like above, he could also rewrite it like:

# ['a', 'b'].each {|item|
#  return if defined? item2module(item)
#}

return if ['a', 'b'].any?{|item|  defined? item2module(item) }

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

Agreed.

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

So it would be just a matter of finding a better name, right? Not that I 
think it should make any difference because ideally only Ruby internals 
should see such errors in my opinion.

But if he thinks StopLoading is too long (while I find it short) it will 
be hard to find a shorter meaningful name I guess.

Maybe after a good night of sleep, who knows...