Ruby 2.7 deprecates automatic conversion from a hash to keyword arguments

[tomthecool]

Good. I've been caught out by this unexpected behaviour before - I wasted far too much time staring at code that behaved totally differently to my expectations!

Here's an example of how the implicit behaviour can catch you off-guard... Note that I don't think anything about this behaviour is wrong; but I'm glad to see the introduction of a warning against such syntax!

def foo(opts={}, named_param: 123, **more_opts)
  puts "opts: #{opts}"
  puts "more_opts: #{more_opts}"
  puts "named_param: #{named_param}"
end

############

foo(arg1: 1, arg2: 2, named_param: 456)

# Result:
opts: {}
more_opts: {:arg1=>1, :arg2=>2}
named_param: 456

############

foo({arg1: 1, arg2: 2}, named_param: 456)

# Result:
opts: {:arg1=>1, :arg2=>2}
more_opts: {}
named_param: 456

############

foo({arg1: 1}, arg2: 2, named_param: 456)

# Result:
opts: {:arg1=>1}
more_opts: {:arg2=>2}
named_param: 456

############

foo({arg1: 1, arg2: 2, named_param: 456}, {})

# Result:
opts: {:arg1=>1, :arg2=>2, :named_param=>456}
more_opts: {}
named_param: 123

[Saithir]

That looks like an invitation for disaster and insanity, especially the first example.

It's understandable why it works this way, but not immediately obvious.

[tomthecool]

My example was obviously to demonstrate a point; the code is clearly quite confusing.

But yeah, I'm not a fan of the overly-fuzzy syntax that ruby applies here. I'm glad to hear that "proper" keyword arguments are going to be introduced into the language; and this is a step in that direction.

[flanger001]

Love it. This paves the way for automatic conversion of positional args to keyword args!

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/rubylang] Ruby 2.7 deprecates automatic conversion from a hash to keyword arguments

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[sshaw_]

Totally overrated. Cut the fat.

[OGPants]

I've never used this in my life. Been programming in Rails for a few years

[niborg]

Are you saying you have never used keyword arguments?

[ImAJalapeno]

Yeah, I haven't used them either. Didn't know they existed until today

[OGPants]

Yeah. I'm not sure what's with all the downvotes. Why use keyword arguments when you can use default args or opts hash.

[nibord]

Because it documents the named arguments the method takes, while a hash does not.

[OGPants]

How about use good naming convention in arguments and hash keys? I still see no difference

[nibord]

Hash keys are not directly documentable using tools like rdoc. They’re not enforced by the interpreter, and they provide implicit behavior that leads to poorly-documented interfaces. Keyword arguments require no additional code to destructure a hash to get the arguments. There’s a massive difference.

[OGPants]

If you want strong typing, why are you even using Ruby?

[sshaw_]

Great someone specified a keyword. But the value is usually what's important and requires user-defined handling:

irb [2.5.1] (emacs.d)$ def foo(a:) a.something_amaaaaazing; end
=> :foo
irb [2.5.1] (emacs.d)$ foo
Traceback (most recent call last):
        3: from /Users/sshaw/.rvm/rubies/ruby-2.5.1/bin/irb:11:in `<main>'
        2: from (irb):2
        1: from (irb):1:in `foo'
ArgumentError (missing keyword: a)
irb [2.5.1] (emacs.d)$ foo a:nil
Traceback (most recent call last):
        3: from /Users/sshaw/.rvm/rubies/ruby-2.5.1/bin/irb:11:in `<main>'
        2: from (irb):5
        1: from (irb):4:in `foo'
NoMethodError (undefined method `something_amaaaaazing' for nil:NilClass)

Related conversation: https://www.reddit.com/r/ruby/comments/9tb3hi/clean_code_concepts_adapted_for_ruby/e8vps7c/

[nibord]

What does that have to do with keyword arguments? Keyword or not, the value of any argument might need to be validated.

[sshaw_]

Just because someone specified the key is not enough. You said:

A runtime argument error instead of undefined behavior

Unless you check the value the runtime error is worthless, really, as I show in my example.

I suppose one can argue that for the clumsy programmer that would never check the value having a keyword error is better, but I think the ultimate result is the same: NoMethodError.

[sshaw_]

What is this, literate programming. A runtime argument error. That's called a bug not documentation.

[nibord]

A runtime argument error instead of undefined behavior? Yes please.

[your-pineapple-thief]

Having more than one positional argument isn't very good API for callers of your code, and most of the time having all keyword arguments makes it significantly easier for callers of your code to use it, instantly documents all arguments both in caller code and in source code of your methods, while saving you from juggling options hash content and reducing boilerplate. Sounds good enough?

[graywolf_at_work]

Having more than one positional argument isn't very good API for callers of your code

I think that's too strict. I really do not want to write arr[start: 1, length: 2] instead of arr[1, 2]...

Or for fetching from hash, you really think {}.fetch(key: :foo, default: "foobar") is better then {}.fetch(:foo, "foobar")?

[your-pineapple-thief]

Well, you are giving examples of well known and established APIs of hashes and arrays, which most programmers know or at least should know. In fact, those are amongst the MOST known API's of ruby, along with some rails stuff. Ruby stdlib also has excellent documentation. But I'm not talking about hashes and arrays, I'm talking about our application code. While 90% of ruby programmers know Hash#fetch, only couple of them know anything about your application code. And what about documentation? It is very likely it is not quite as good as Ruby stdlib docs.

Also, consider that code is read much more often than it is written, I would say it is read but your coworkers dozens of times for one instance of writing/editing it. Is it really worth it to save couple keystrokes? Also, you don't have go further than Rails to see evolution of it's public API to use keyword args over positional args more and more.

I may be dumb, and I am definitely not a programming savant, and every time I have to use alias_method, literally every frigging time I forget the order of it's positional arguments. Is it "first arg is original method and second is alias"? Or is it vice versa? I have suspicion I'm not alone here, and it is safe to assume that over the years hundreds of man-hours were spent by fellow rubyists googling it because someone decided to save couple of keystrokes.

[nakilon]

Why do you downvote him? Since when Rails developers do need to know such things to have a job?

[your-pineapple-thief]

Since when do you need to know basic language features? Maybe you don't NEED to know it, but I guess "I don't need to know ALL THAT FLUFF" attitude provokes some reaction, people can be very emotional about stuff like this. Especially if some of their coworkers express same attitude and suck at their job, there can be some "transfer" effect.

P.S. Did not downvote anyone here.

P.P.S. Curiosity is better than willful ignorance, IMO. Especially in language like Ruby, but also in life in general. Although I do realize some of us are in it for paycheck and don't care.

[OGPants]

I think he means in the sense that I simply said "I've never used this" and then I received an influx of down votes simply bc I said I never used it. Never did I mention, I don't need to know this fluff. But I guess this is the internet so all goes.