From: "headius (Charles Nutter)" <headius@...>
Date: 2013-09-15T19:46:17+09:00
Subject: [ruby-core:57213] [ruby-trunk - Feature #8909] Expand "f" frozen	suffix to literal arrays and hashes


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


@matz At this point I'm leaning toward just doing a simple shallow freeze. It would be up to the user to put things into the array that are themselves literals or frozen (or perhaps the user doesn't necessarily want those contents to be frozen). I'm seeing this as mostly a quick way to create a frozen array so a consumer (API, library, etc) won't be changing the array contents. It's your responsibility to make the array's contents' contents are also safe, if you want them to be.

I know folks may cry foul because they have always wanted deep freezing, but there is currently no deep freeze in Ruby. Shoehorning it into []f and {}f seems like it would be putting the cart before the horse.
----------------------------------------
Feature #8909: Expand "f" frozen suffix to literal arrays and hashes
https://bugs.ruby-lang.org/issues/8909#change-41825

Author: headius (Charles Nutter)
Status: Open
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/