Add Hash#put_if_absent

[HertzDevil]

Resolves #8660.

This is faster than hash[key] ||= value for two reasons:

• If the given key cannot be found, Hash#insert_new will not attempt to match the key against any existing keys at all. (This suggests that find_entry_with_index followed by set_entry or insert_new might be faster than upsert too, which makes #upsert completely unnecessary, but I haven't verified that.)
• A missing key goes directly to insert_new, whereas ||= means any existing value must be upcast to a nilable value and evaluated for truthiness first.

Instead of #insert_new, perhaps a copy of #upsert that traverses existing keys but doesn't update them could be defined?

Hash-like types such as ENV.class and URI::Params do not have this. For those types it might be better if a generic implementation is offered via #10886.

[kostya]

is not put doing the same?

[HertzDevil]

#put always updates the given key like #[]=, only that it returns a different thing

[Sija]

Local variable makes it more readable

[straight-shoota]

Do you mean this?

Suggested change

	lines_cache.put_if_absent(file) { File.read_lines(file) }[line - 1]?
	lines = lines_cache.put_if_absent(file) { File.read_lines(file) }
	lines[line - 1]?

Then I agree =)

[Sija]

yup :)

[Sija]

Once could argue that the .put_if_absent(file) { File.read_lines(file) } << item constructs are bit overly complicated as well.

[asterite]

Too many API options. Why not keep it simple? What's a case where the existing way is too slow?

[beta-ziliani]

A little benchmark shows some non-negligible improvement when keys are absent:

          ||=   1.88M (531.95ns) (± 2.12%)  448B/op   1.22× slower
put_if_absent   2.29M (436.61ns) (± 1.55%)  448B/op        fastest

When keys aren't absent, then it's negligible.

[straight-shoota]

The performance impact depends on the hash complexity. But calculating the hash only once instead of twice is always a good improvement, even for simple keys.

As #8660 (comment) shows, this is a very common API method for hash map implementations. Maybe not as concise as in Crystal but surely these languages have other ways to implement that with an added overhead of double hash calculation.

[straight-shoota]

I'd prefer the above code suggestion, but I'm happy to merge with or without it.

[asterite]

Why is there no equivalent API in Ruby, I wonder?

[straight-shoota]

I can only speculate on that... Ruby's Hash API generally seems to be a bit bare. I believe methods like #transform_values and #transform_keys are even relatively recent additions (in Ruby's timeline).

Anyway, regardless what Ruby is doing, this method seems to be very reasonable to me. Its optimization effect is basically a no-brainer.
Sure, it adds another tool in the toolcase that you have to know about. But the name is pretty self-explanatory.
I don't think this is bloating the API with unneccessary stuff. It's a useful enhancement.

[HertzDevil]

It is indeed proposed to Ruby in relatively recent times, called #fetch_set: https://bugs.ruby-lang.org/issues/17342