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

Status changed from Feedback to Open

matz (Yukihiro Matsumoto) wrote:
> I ... had problem with how to detect non block calling block.

Sorry, I am not sure I understand completely.

To avoid case like the example I gave, we could modify "rb_mod_const_set" by adding "WARN_IF_BLOCK_GIVEN", for example, or create a more advanced version of "rb_check_arity" like "rb_check_arity_and_block" that accepts a parameter to warn if there is a block given.

What I would *really* like to do is create an improved "rb_define_method" with arguments to specify:
* mininum arity
* maximum arity
* if block is accepted
* and ideally parameter names, at least for methods with simple interfaces

This way:
* easier to warn if block is accepted
* improved result for `"".method(:gsub).arity`
* much improved result for `"".method(:gsub).parameters`
* possible to implement `arity_max` or `arity_range` with good result if ever it is accepted
* improved behavior when using `curry`

Also, this would simplify many method that would not have to call `rb_check_arity` like we do now.

----------------------------------------
Feature #7299: Ruby should not completely ignore blocks.
https://bugs.ruby-lang.org/issues/7299#change-32542

Author: marcandre (Marc-Andre Lafortune)
Status: Open
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/