https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112018-11-28T11:05:56ZRuby Issue Tracking SystemRuby master - Feature #15352: Mandatory block parametershttps://bugs.ruby-lang.org/issues/15352?journal_id=752362018-11-28T11:05:56Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>This is an interesting suggestion in the sense that block parameters,<br>
or rather, blocks as a whole, are a bit like additional arguments to<br>
every method in ruby, at all times, optional; but they are also quite<br>
special entities in ruby. For example, to use .call on a proc; is a<br>
bit similar to yield, and unbinding/rebinding a method and passing<br>
this as a block to another method.</p>
<p>Typically if we have a method such as foo(), in ruby we can call it<br>
via:</p>
<pre><code>foo()
foo
foo { :something }
</code></pre>
<p>All three ways are more or less the same, except for the last which<br>
pushes more information onto the method foo; but that information<br>
may not be evaluated within the method body (of foo).</p>
<p>I think this is where matz should come in since he designed ruby<br>
and added blocks, so he knows best how blocks are seen (from within<br>
ruby itself). I could see it go either way with statements, where<br>
ruby users may say that block parameters should behave like regular<br>
parameters of methods; or that blocks are special and so block<br>
parameters should also be special. I myself have no real preference<br>
either way. I think backwards compatibility and backwards behaviour<br>
may be a reason in retaining the present behaviour, though; but again,<br>
I am neutral on the feature suggestion in itself. We can also reason<br>
that this would allow for more functionality, since he would gain the<br>
ability to cause blocks to raise an error, in this case an<br>
ArgumentError.</p>
<p>There is, however had, one part I slightly dislike, and that is the<br>
syntax. I don't have an alternative suggestion, which is bad, but<br>
I don't like the close associoated of &! there. Perhaps my opinion<br>
is partially affected by other unrelated suggestions, e. g. to add<br>
arguments to &: invocation styles, such as &.: or variants that<br>
use even more characters. But anyway, I guess the syntax is partially<br>
separate from the suggested functionality, so I think it may be<br>
best to ask matz about the principle situation first, that is whether<br>
block arguments should/could behave like regular methods too (specifically<br>
whether they should be able to raise ArgumentError, if a ruby user wants<br>
to have it that way).</p>
<p>One last point; not sure if they are worth mentioning but I will mention<br>
it, if only for symmetry:</p>
<ul>
<li>
<p>In regular parameters signature we have something like:</p>
<p>def foo(bar = '')<br>
def foo(bar)</p>
</li>
</ul>
<p>In the second case we must supply an argument; in the first, the default<br>
will be to an empty String ''. I understand that this can not be the same<br>
for blocks, at the least not without changing how they behave, but I wanted<br>
to point this out because to me this is quite different in behaviour and<br>
syntax, from the proposed &! or any similar proposal - I guess it all has<br>
to be different to the two method definitions above.</p>
<p>Anyway, I wanted to write a bit more, but I tend to write too much so I will<br>
stop here.</p> Ruby master - Feature #15352: Mandatory block parametershttps://bugs.ruby-lang.org/issues/15352?journal_id=752392018-11-28T12:19:56Zsawa (Tsuyoshi Sawada)
<ul></ul><p>I don't find this feature useful. If you wanted to raise an error when no block is given, all you have to do is call <code>yield</code> within the method body, which will not be an extra code if you are going to use the block somewhere in the method body.</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">def</span> <span class="nf">foo</span>
<span class="o">...</span> <span class="k">yield</span> <span class="o">...</span>
<span class="k">end</span>
<span class="n">foo</span>
<span class="c1"># >> `foo': no block given (yield) (LocalJumpError)</span>
</code></pre>
<p>And in case you want to return an error with a different message, then that is when you want to implement your custom validation clause in your code like the ones found in the examples that you have searched.</p>