Issue #7299 has been updated by marcandre (Marc-Andre Lafortune).


ko1 (Koichi Sasada) wrote:
>  If compiled method does not contain
>   - `yield' statement
>   - super statement
>   - block argument
>  then the method is marked as "block is not needed" method.
>  
>  This approach introduce incompatibility because we can call block in `eval'.
>  
>  And maybe there are other issues.

There is also `Proc.new`...

    def foo
      Proc.new.call
    end

    foo{ p 42 } # => prints 42

Both eval and Proc.new are strange cornercases though. The only valid uses I can think of for `Proc.new` also imply use of `super`.  If we only issue a warning, the incompatibility would be very minimal.

So I'll make a proposal for an expanded API for `rb_define_method`. OTOH, marking ruby methods as {non-}block taking would seriously challenge my cruby skills
----------------------------------------
Feature #7299: Ruby should not completely ignore blocks.
https://bugs.ruby-lang.org/issues/7299#change-32646

Author: marcandre (Marc-Andre Lafortune)
Status: Rejected
Priority: Normal
Assignee: 
Category: core
Target version: 


Ruby should not completely ignore blocks.

  const_set :Example, Class.new do
    p "Hello, world"
  end
  # Doesn't print anything, generate any warning nor error.

To minimize any impact, Ruby should issue a warning, and in future version could even raise an error.

Even unused variables provide warnings in verbose mode, and they have their use.

I can't think of a case where passing a block to a builtin method that doesn't accept a block is not a programming error though.

If this is approved, I volunteer to implement this.



-- 
http://bugs.ruby-lang.org/