Daniel Schierbeck wrote:
> key => value
>
>    def foo(a => "default", **keys)
>    foo(a => "foobar")
>
>    pro: It's what being used at the caller-level already. It looks cool,
>         even when the value's a symbol: foo(a => :b).
>
>    con: To me, => means "points to", not "is". Therefore it might not be
>         good as an assignment symbol. No way to specify a named argument
>         without a default value.

There's no reason you can't leave the value off.

  def foo(a=>)  # same as foo(a=>nil)

I'm not saying its great. But it would work. And the pros for this are
pretty signifficant.

The 'key: :sym' effect is very unfortunate. I use symbol argument in a
number of places. Whether I will use them with keys much, who knows,
but given the problem I probably just won't and may even end up only
using => so as to avoid it. Then the ':' may as well not exist. I don't
know. But it sure would be nice if there was a simple fix to this.
Perhaps if backticks can become an *additional* way to express a
symbol? I know they are currently used for a type of system call, but
I'm sure a regular method would be okay for that. And I don't think
that's too much to ask of Ruby 2.0. Seems like a reasonble solution.

Of course there's still the question of Evan vs. Matz keyword
arguments. I can go either way. I think we all pretty much can go
either way. We know one works fine for Python, we know the other works
fine for Lisp. Is one truly better than the other? Doesn't seem like it
--at least not by much. Mostly, they're just different. Pick one.

T.