From: "marcandre (Marc-Andre Lafortune)" Date: 2012-11-09T01:53:11+09:00 Subject: [ruby-core:49115] [ruby-trunk - Feature #7299] Ruby should not completely ignore blocks. 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/