do not enforce hash rockets, prefer 1.9 hash literal syntax

[tonyta]

Since support for 1.8.7 is long gone, and since all supported versions of Ruby support keyword args, it seems like a good time to prefer the use of the 1.9 alternate hash literal syntax, enforced by default by Rubocop.

[britishtea]

You lose the ability to quickly see if you're passing a hash or passing keyword arguments this way.

[ixti]

Hash rocket style was enforced due to personal flavors. I don't find new hash syntax worth using it.

{ :foo => { "Bar" => 123 } }

# looks more consistent than:

{ foo: { "Bar" => 123 } }

[ixti]

Thanks for the efforts, but I am pretty strongly against this change. Until hash-rocket will become deprecated - I don't see any good reason to switch to the new style.

[ixti]

Re: rubocop defaults. I find some of it's code style defaults to be pretty stupid.

[tonyta]

No problem! Thanks for your time @ixti! 😸

[tarcieri]

For what it's worth, I like the new syntax 😜

[zanker]

Haha yea I'd +1 on liking the new syntax, but also it's becoming more common so having inconsistency seems a little odd.

[sferik]

Since we’re all weighing in on hash syntax, I prefer the classic rockets, since they can be used consistently (regardless of key type) and are less ambiguous.

POP QUIZ

What is the result of the following statement?

 {"foo": "bar"}

It looks like the key is a string but it actually gets converted to a symbol, unless you’re using Ruby 2.1 or earlier, in which case it produces a SyntaxError. If you consistently use hash rockets, this ambiguity can be avoided. Plus, you get the benefit of not mistaking hashes for keyword arguments mentioned earlier.

The hash rocket syntax will not be deprecated until the colon syntax can handle non-symbol keys, which would be a breaking change in cases like {true: "fizz", false: "buzz"}. I doubt Matz will ever agree to this, so—for better or for worse—hash rockets are here to stay.

[tarcieri]

I use the colon syntax and keyword arguments pretty frequently now, in addition to hashrockets. The style is basically this:

Want a hash with symbols as keys or kwargs? Use the new syntax.
Want to construct a hash with keys that are anything but symbols? Use hashrockets. TIMTOWTDI!

Re: hash vs kwargs, this lets you retroactively upgrade APIs that previously took options hashes to use kwargs. Switching from options hashes to kwargs gives you better runtime checking in terms of the arguments passed (e.g. unknown kwargs are automatically an error), so I see this as a benefit instead of a problem. We just phased out 1.9 support, so "upgrading" our APIs to kwargs is a (mostly) backwards compatible option (although it would break users passing bogus options).

There are a few places I feel the syntax "leaks" in practice, specifically around the quoted symbol syntax @sferik was talking about. The biggest problem I've encountered is wanting to have keys which contain a - character since this is interpreted by Ruby as a literal - character and the surrounding text as locals:

[1] pry(main)> {foo-bar-baz: 42}
SyntaxError: unexpected ':', expecting =>
{foo-bar-baz: 42}
             ^
[1] pry(main)> {"foo-bar-baz": 42}
=> {:"foo-bar-baz"=>42}