From: George Ogata <g_ogata@...>
Date: 2004-07-07T23:32:39+09:00
Subject: Re: Array::index and rindex operator

"David A. Black" <dblack@wobblini.net> writes:

>> But to answer David( Black)'s concern, I think the only sane choice is
>> to raise an exception when both are given.  It's ambiguous, so it's an
>> error, right?
>
> It's an interesting problem, since the existence of #block_given?
> suggests that branching on the presence/absence of a block is legit,
> though these instances show that for this purpose it can be rather
> messy.  
>
> I tend to favor the exception approach, though one could also argue
> for a left-to-right logic: if a method needs an argument xor a block,
> then once it gets an argument, let it be satisfied and ignore the
> block (which is also a legit and indeed default action).  One would
> then have to be careful not to have stray useless blocks, but that's
> already the case; one already could, but presumably would not, do
> this:
>
>   /blah/.match(str) { puts "useless block!" }

Well, one could also counter-argue that in the useless-block cases
it's not ambiguous, though I think ideally, ruby should still
complain.  I guess it doesn't due to a combination of ruby's dynamic
nature (it can't determine for itself whether or not a block might be
needed at compile time, and it's inefficient to check it at runtime),
and ruby's "no declarations" philosophy (i.e., no declaring "I take
blocks" in the method definition).  Perhaps also because a useless
block isn't an oft-made mistake.

As for the "left-to-right" view, there's no precedence for this being
silently ignored in the presence of ambiguity, is there?