Issue #8909 has been updated by headius (Charles Nutter).


Any other thoughts on this? Any other reasons why it shouldn't be done?

There are other advantages to having literal frozen array and hash:

* Alternative representation of small hashes knowing they won't need to change. Good for smaller footprint on hash args, for example.
* Small arrays could pack elements into the header (this may be happening already, but there would be less need to recover as it grows).

And the already-discussed advantages:

* []f and {}f would be the same object everywhere, making for cheap argument defaults.
* Assurance that your array or hash won't have different elements after passing to another piece of code.
* Returning the same object when all elements are literals
----------------------------------------
Feature #8909: Expand "f" frozen suffix to literal arrays and hashes
https://bugs.ruby-lang.org/issues/8909#change-41979

Author: headius (Charles Nutter)
Status: Feedback
Priority: Normal
Assignee: 
Category: 
Target version: 


The "f" suffix to declare a frozen string was recently accepted into 2.1, and I think it's a spectacular addition. I would very much like to see it work for literal arrays and hashes too:

[1, 2, 3, 4, 5]f

{foo: 1, bar: 2, baz: 3}f

There are many, many cases where this could reduce allocation (frozen array with literal elements would only need to be allocated once) and improve thread-safety (explicitly create frozen arrays and hashes when creating structures that might be used across threads).

Is there any reason why we could not do this? I believe both of the above syntaxes would be invalid today, as was the case with the String "f" suffix, and hopefully that means the work to add this syntax would be similar.


-- 
http://bugs.ruby-lang.org/