On Sun, Sep 26, 2004 at 04:19:55AM +0900, Markus wrote:
> > (3) It may be possible to keep Ruby's automagic exploding of arguments, if
> > we limit it to cases where there is no ambiguity. I am thinking of:
> > 
> >   - the sender passes a single array value;
> >   - the receiver REQUIRES two or more arguments.
> > 
> > This is unlike def foo(head,*rest) or proc {|head,*rest| ... }, where it can
> > take _one_ or more arguments, so the rule would not apply.
...
>      I played around with this idea (briefly) yesterday before posting. 
> I reached the (tentative) conclusion that any attempt to retain
> auto-explosion and enforce consistency would blow up.  The goatch for
> this one: if a method required two arguments and was passed an array by
> some user, changing the method so that the second argument was optional
> would (instead of required) would silently change what was passed in for
> the second argument--it would now get the array, and the second would
> get the default.

True, but if you change the number of parameters which a (method|proc|block)
expects, then you're almost certain to change the semantics anyway.

In the case I'm thinking of, Ruby would otherwise have raised an
"ArgumentError: wrong number of arguments (1 for 2)". So you're still
changing the semantics by making the second argument optional.

So I believe it's a question of which is more useful: the ArgumentError
(perhaps making it quicker to track bugs due to wrong number of arguments
being passed), or to auto-explode.

Somehow I feel happier retaining this for blocks, for backwards-
compatibility with 1.8.x, than to introduce it for method calls for
consistency:

  def foo(a,b)
    # ...
  end

  a = [1,2]
  foo(a)      # Feels like this *ought* still to raise an ArgumentError

How do people feel about

  myhash.each{|key,value| ... }

raising an ArgumentError, forcing you to rewrite it as

  myhash.each{|(key,value)| ... }

?

Regards,

Brian.