¿Cómo se comporta foo (& nil) de forma diferente que foo (& "not a proc")?

Question

supe por heckle que

[1, 2, 3].each(&nil) 

no causa ningún error - simplemente devuelve un enumerador.

Por el contrario,

[1, 2, 3].each(&"") 

plantea

TypeError: wrong argument type String (expected Proc) 

Además, &nil causas block_given? para volver falsa

def block_given_tester 
    if block_given? 
    puts "Block given" 
    else 
    puts "Block not given" 
    end 
end 

block_given_tester(&nil) # => Block not given 

No es porque NilClass implementa to_proc - Revisé la RDoc.

puedo entender por qué que sería bueno tener &nil, pero no estoy seguro de cómo se hace. ¿Es esta una de las maneras en que nil tiene un comportamiento especial no compartido por otros objetos?

Answer 1

La respuesta se puede encontrar mirando el código fuente de Ruby.

Rubí 1.8:

observar la función block_pass en el archivo eval.c. Tenga en cuenta que trata nil especialmente desde objetos Proc (la macro NIL_P). Si la función pasa un valor nulo, evalúa un bloque vacío (creo) y lo devuelve. El código justo después de que comprueba si el objeto es un objeto Proc (la función rb_obj_is_proc) y plantea la excepción "tipo de argumento incorrecto (Proc esperado") si no lo es.

de Ruby 1.9.2:

Mira el método caller_setup_args en el archivo vm_insnhelper.c. Convierte el proceso con to_proc solo si no es nulo; de lo contrario, la conversión de tipo y la verificación de tipo quedan anuladas.