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


Has this already been excluded from 2.1.0? May I ask why? We have not finished discussing it and most folks on this issue believe it would be a good feature to have.

After hearing Tony's case about the value of []f and {}f being more useful if they checked for frozen elements, I'm coming around to that idea. So in both cases, the guarantee would be that the object you get back (the Array or Hash) is frozen and the elements it contains are #frozen? (which may or may not say anything about the data *they* contain). If any elements are not frozen (or not literals, though I believe all literals will be frozen in 2.1), you'd get an error... "cannot create frozen {Array,Hash} with unfrozen elements".

I would like to understand the justification for moving this to "next minor" without more discussion.
----------------------------------------
Feature #8909: Expand "f" frozen suffix to literal arrays and hashes
https://bugs.ruby-lang.org/issues/8909#change-42171

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


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/