From: Yukihiro Matsumoto <matz@...>
Date: 2008-06-09T18:22:57+09:00
Subject: [ruby-dev:35013] Re: [ruby-changes:5517] Ruby:r17021 (trunk): * vm_insnhelper.c, vm.c, proc.c (proc_call): allow call method with

まつもと ゆきひろです

In message "Re: [ruby-dev:35007] Re: [ruby-changes:5517] Ruby:r17021 (trunk): * vm_insnhelper.c, vm.c, proc.c (proc_call): allow call method with"
    on Mon, 9 Jun 2008 12:43:33 +0900, "Yusuke ENDOH" <mame@tsg.ne.jp> writes:
|
|真に「ちゃんと説明できない仕様」なのは、ブロック引数を受け取る
|ブロックが C で書けないことだと思います (Ruby では書けるのに) 。
|つまり foo {|&b| ... } のような呼び出しが C では表現できません。

|さらに、[ruby-core:15927] でもこの話で困っている人がいるようです。
|ブロック引数を受け取るブロックが普及したら、もっと大きな問題になる
|可能性が高いと思います。

ふむ、なるほど。

|で、ささださんの 2) の案である ifunc の仕様変更が許されるのならば、
|ANYARGS をやめればいいんじゃないでしょうか。
|
|VALUE rb_iterate(VALUE(*)(VALUE),VALUE,VALUE(*)(ANYARGS),VALUE);
|
|から
|
|VALUE rb_iterate(VALUE(*)(VALUE),VALUE,rb_block_call_func*,VALUE);
|
|に変更すれば、「2 については，今は rb_iterate に渡す関数ポインタの
|引数が ANYARGS なので無理です」という問題がなくなると思います。
|
|実際にこのように変更してみたところ、make 時に型整合性で大量の警告が
|出ますが (これは修正可能) 、make test も make test-all も通りました。

rb_block_call_funcにはブロック引数があるかどうかの情報は含ま
れていないような気がするんですが、それはrb_block_call_funcそ
のものを今後拡張すると言う意味でしょうか。

その辺がクリアになれば(若干のCレベルでの非互換性が発生します
が)、変更してもかまわないような気がして来ました。