https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112013-09-14T17:46:35ZRuby Issue Tracking SystemRuby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418042013-09-14T17:46:35ZAnonymous
<ul></ul><p>+1</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418052013-09-14T17:54:53Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>A couple questions:</p>
<ul>
<li>If you have literal arrays/strings/hashes within a frozen literal array/hash, should the "f" suffix do a "deep freeze" or do you have to specify each one?</li>
</ul>
<p>in other words, if I want this whole thing to be frozen, do I need to do:</p>
<p>[[1, 2]f, {foo: 3}f, "blah"f]f</p>
<p>or</p>
<p>[[1, 2], {foo: 3}, "blah"]f</p>
<p>I can see pros and cons both ways.</p>
<ul>
<li>
<p>Is there any problem with "f" suffixes always returning the same object when the contents are the same and also immutable? I have not looked at the implementation in MRI for "foo"f, but it <em>should</em> be totally ok for it to always return the same object. [:foo, 1, 2.0]f should be the same thing.</p>
</li>
<li>
<p>Special syntax for frozen empty array</p>
</li>
</ul>
<p>A great number of wasted Ruby objects are caused by needing to simply pass or return an empty array. Because Arrays are mutable by default, [] always has to return a new object. The same goes for hashes.</p>
<p>For example, in method definitions:</p>
<p>def foo(opts = {}) # new hash created every time and probably doesn't need to be mutable<br>
def bar(args = []) # new array created every time and probably doesn't need to be mutable</p>
<p>So with this proposal, we'd have []f and {}f, which aren't too bad...but I wanted to throw out the possibility of some other magic syntax. I have no strong preference or ideas.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418062013-09-14T19:04:31ZAnonymous
<ul></ul><blockquote>
<ul>
<li>Is there any problem with "f" suffixes always returning the same object when the contents are the same and also immutable?</li>
</ul>
</blockquote>
<p>CRuby already does this for f-suffixed strings. See r42843 and r42847.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418072013-09-14T20:42:58Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>charliesome (Charlie Somerville) wrote:</p>
<blockquote>
<p>CRuby already does this for f-suffixed strings. See r42843 and r42847.</p>
</blockquote>
<p>Excellent...as I hoped.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418082013-09-14T21:22:28Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>"string" is a literal, but {a: 1} and [1, 2] are expressions.<br>
Thus we have to define {}f and []f to be shallow freezing or deep freezing.<br>
If it's deep freezing, freezing objects (not literals) could be troublesome.</p>
<p>We have to define a concrete behavior first to discuss.</p>
<p>Matz.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418092013-09-14T23:40:37ZHanmac (Hans Mackowiak)hanmac@gmx.de
<ul></ul><p>what about []f for shallow-freezing and []df for deep freezing? ;D</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418152013-09-15T13:20:40Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/3055">@Hanmac (Hans Mackowiak)</a>, Currently Ruby does not have object traversal API (except for marshalling and GC, both are not disclosed to Ruby level).<br>
Deep freeze is far more difficult than you might expect.</p>
<p>Matz.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418162013-09-15T13:27:49Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Options I can provide are:</p>
<ul>
<li>shallow freeze</li>
<li>shallow freeze, and raises error if elements are not literals</li>
<li>deep freeze, and raises error if elements are static freezable (i.e. numbers, strings, hashes and arrays)</li>
</ul>
<p>Pick one, or propose alternative, if you want frozen suffix for hashes and arrays.<br>
It's kind of trade off between complexity and usability.</p>
<p>Matz.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418252013-09-15T19:46:16Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> 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.</p>
<p>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.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418262013-09-15T19:51:46Zphluid61 (Matthew Kerwin)matthew@kerwin.net.au
<ul></ul><p>+1 to shallow freeze</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418272013-09-15T20:01:13Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>FWIW, I would still optimize frozen-arrays-of-literals to always return the same object, and frozen empty arrays and hashes would be the same object everywhere, but the expression nature of the array elements means this would be an unspecified characteristic of the feature.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418332013-09-15T22:35:58Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>@hedius I don't think same object optimization coexists with mere shallow freezing.<br>
If we restrict elements in static frozen containers to be static freezable, it would be possible.<br>
But it makes implementation more complex. It's trade off.</p>
<p>Matz.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418392013-09-16T03:29:35Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> What I mean is that all of the following could safely be optimized to return the same object every time:</p>
<p>[]f<br>
{}f<br>
[:foo, 1, 1.5, true, nil]</p>
<p>I cannot decide whether restricting the elements to be literals and/or statically frozen is a good idea or not. For example, something like this seems like it should be acceptable:</p>
<p>{cache: ThreadSafe::Hash.new}</p>
<p>It wouldn't be able to optimize to be the same object every time, but it would still be a frozen Hash and nobody downstream could change the keys/values it stores.</p>
<p>So I guess the question is whether shallow freeze with potentially mutable elements is good or not.</p>
<p>Pros and cons:</p>
<ol start="3">
<li>Shallow freeze, no restrictions</li>
</ol>
<ul>
<li>simplest to implement</li>
<li>most flexible</li>
<li>no side effects</li>
</ul>
<ul>
<li>mutable elements are still mutable</li>
<li>user may expect elements to freeze too</li>
</ul>
<ol start="2">
<li>Shallow freeze, only frozen or literals as elements</li>
</ol>
<ul>
<li>prevents unintentional exposure of mutable elements in frozen collection</li>
<li>no side effects due to deep freezing</li>
</ul>
<ul>
<li>less flexible</li>
<li>user may want elements to be unfrozen</li>
<li>more complicated to implement</li>
<li>frozen elements may have unfrozen elements</li>
</ul>
<ol start="3">
<li>Deep freeze</li>
</ol>
<ul>
<li>Guarantees everything inside frozen collection is deep-frozen</li>
<li>May reflect frozen modifier more clearly</li>
<li>Less typing to freeze all elements</li>
</ul>
<ul>
<li>Most complicated and no existing functionality</li>
<li>Array/Hash creation would deep freeze objects as side effect</li>
<li>May have unintended consequences</li>
</ul>
<p>I'm still leaning toward #1.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418402013-09-16T03:33:28Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>We can probably agree that the deep freezing version is wrong, since it could have the side effect of freezing objects far away from the array/hash. There are no similar side effects for creating an array/hash today.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418442013-09-16T10:59:13Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>(13/09/16 3:29), headius (Charles Nutter) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> What I mean is that all of the following could safely be optimized to return the same object every time:</p>
<p>[]f<br>
{}f<br>
[:foo, 1, 1.5, true, nil]</p>
</blockquote>
<p>Note that we have to freeze true, false, and nil too, for the last<br>
expression.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418452013-09-16T14:53:14Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>On Mon, Sep 16, 2013 at 3:53 AM, Nobuyoshi Nakada <a href="mailto:nobu@ruby-lang.org" class="email">nobu@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>(13/09/16 3:29), headius (Charles Nutter) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> What I mean is that all of the following could safely be optimized to return the same object every time:</p>
<p>[]f<br>
{}f<br>
[:foo, 1, 1.5, true, nil]</p>
</blockquote>
<p>Note that we have to freeze true, false, and nil too, for the last<br>
expression.</p>
</blockquote>
<p>true, false, and nil exist as unique objects, so whether they're<br>
frozen or not does not matter here. Two arrays that contain the same<br>
objects and which cannot be modified are equivalent.</p>
<p>That said, I have and will continue to support all literal,<br>
naturally-immutable values being frozen by default (Symbol, Fixnum,<br>
Float, Bignum, true, false, nil) and values that <em>should</em> be immutable<br>
being frozen as well (Time, Rational, Complex, BigDecimal).</p>
<ul>
<li>Charlie</li>
</ul> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=418962013-09-19T23:04:12Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>(13/09/16 3:29), headius (Charles Nutter) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/13">@matz (Yukihiro Matsumoto)</a> What I mean is that all of the following could safely be optimized to return the same object every time:</p>
<p>[]f<br>
{}f<br>
[:foo, 1, 1.5, true, nil]</p>
</blockquote>
<p>Note that we have to freeze true, false, and nil too, for the last<br>
expression.</p>
</blockquote>
<p><a href="https://bugs.ruby-lang.org/issues/8923" class="external">https://bugs.ruby-lang.org/issues/8923</a></p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=419792013-09-26T06:49:04Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>Any other thoughts on this? Any other reasons why it shouldn't be done?</p>
<p>There are other advantages to having literal frozen array and hash:</p>
<ul>
<li>Alternative representation of small hashes knowing they won't need to change. Good for smaller footprint on hash args, for example.</li>
<li>Small arrays could pack elements into the header (this may be happening already, but there would be less need to recover as it grows).</li>
</ul>
<p>And the already-discussed advantages:</p>
<ul>
<li>[]f and {}f would be the same object everywhere, making for cheap argument defaults.</li>
<li>Assurance that your array or hash won't have different elements after passing to another piece of code.</li>
<li>Returning the same object when all elements are literals</li>
</ul> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=419852013-09-26T14:12:14Zbascule (Tony Arcieri)bascule@gmail.com
<ul></ul><p>I think there's a big opportunity here for immutable collection types... at least the sort that you know at the time you declared it is immutable.</p>
<p>I would hate to see a syntax like this that doesn't guarantee a deeply frozen data structure, since immutable data is quite difficult to use in Ruby at present, and really I've never found frozen data structures to be particularly useful since you can never be sure if they're immutable all the way down. Only then are you able to create immutable persistent data structures ala Ruby libraries like Hamster.</p>
<p>I think there's a way to ensure this is the case without requiring an object traversal system. Let's go back to what Charlie was saying:</p>
<blockquote>
<p>if I want this whole thing to be frozen, do I need to do:<br>
[[1, 2]f, {foo: 3}f, "blah"f]f</p>
</blockquote>
<p>What if this were the <em>only</em> option, i.e. if we tried to do the other thing Charlie asked about:</p>
<blockquote>
<p>[[1, 2], {foo: 3}, "blah"]f</p>
</blockquote>
<p>...it raised an exception, because you asked it to make an immutable array that contained mutable contents?</p>
<p>This check could even be shallow and still be useful, IMO, provided we were vigilant about how things got frozen in the first place. However...</p>
<blockquote>
<p>Is there any problem with "f" suffixes always returning the same object when the contents are the same and also immutable?</p>
</blockquote>
<p>For this to work the VM would need to be in some sense aware that it's frozen objects all the way down. Isn't this state that the VM can track? What if you were simply "unallowed" to make deep frozen objects with references to other objects that aren't deep frozen?</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=421242013-10-01T09:40:28Zheadius (Charles Nutter)headius@headius.com
<ul><li><strong>Target version</strong> set to <i>2.1.0</i></li></ul> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=421482013-10-01T17:16:59Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Target version</strong> changed from <i>2.1.0</i> to <i>2.6</i></li></ul> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=421712013-10-02T03:11:52Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>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.</p>
<p>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 <em>they</em> 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".</p>
<p>I would like to understand the justification for moving this to "next minor" without more discussion.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=421722013-10-02T03:12:26Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>Also, FWIW, ko1 told me to mark the bugs I was interested in as 2.1, which is why I set this bug for 2.1.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422042013-10-02T14:35:37Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>headius (Charles Nutter) wrote:</p>
<blockquote>
<p>Also, FWIW, ko1 told me to mark the bugs I was interested in as 2.1, which is why I set this bug for 2.1.</p>
</blockquote>
<p>Therefore we discussed about this on RubyDeveloperMeeting20131001.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Through the meeting, I thought it is hard to get consensus about this spec, for example shallow or deep,<br>
literal item or variable or methods.</p>
<blockquote>
<p>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 <em>they</em> 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".</p>
<p>I would like to understand the justification for moving this to "next minor" without more discussion.</p>
</blockquote>
<p>If a feature needs more discussion, it will drop from 2.1.0; this is the decision of I, release manager.</p>
<p>Anyway this feature doesn't affect ruby's stability at the implementation view.<br>
Therefore it can be accepted to 2.1 feature if someone works hard to make the spec and get consensus.<br>
The deadline is the end of October.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422312013-10-03T04:42:00Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>headius (Charles Nutter) wrote:</p>
<blockquote>
<p>Also, FWIW, ko1 told me to mark the bugs I was interested in as 2.1, which is why I set this bug for 2.1.</p>
</blockquote>
<p>Therefore we discussed about this on RubyDeveloperMeeting20131001.</p>
</blockquote>
<p>It is unfortunate these meetings cannot be attended by other implementers. Was this only for Japanese-speaking contributors?</p>
<blockquote>
<p>If a feature needs more discussion, it will drop from 2.1.0; this is the decision of I, release manager.<br>
...<br>
Anyway this feature doesn't affect ruby's stability at the implementation view.<br>
Therefore it can be accepted to 2.1 feature if someone works hard to make the spec and get consensus.<br>
The deadline is the end of October.</p>
</blockquote>
<p>Ok, I will try to get consensus on this feature by end of October.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422322013-10-03T04:55:32Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I have started a wiki page for the proposal: <a href="https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/Frozen_Array_and_Hash_literals_proposal" class="external">https://bugs.ruby-lang.org/projects/ruby-trunk/wiki/Frozen_Array_and_Hash_literals_proposal</a></p>
<p>Please comment here or make comments as edits there.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422342013-10-03T07:20:44Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>My take on this proposal is that deep and shallow freezing is not as important as knowing that the 'f' (which I think should mean fixed and not frozen) is that once the array literal evaluates it will not be possible to change its size. What is inside can change but that is ok. At a grammar level we know we can alloc an array of n elements once and never need to worry about allocating it again.</p>
<p>On top of that if the literal only contains immediate values or frozen/fixed literals then we can do a bunch of other optimizations. Like never populate the array more than once. Or even constant propagate elements to where they are used if we know [] is not overriden. In my mind, the 'f' gives us a whole dimensions of things which we can do internally to improve performance.</p>
<p>For a Ruby programmer it means they can never change the size of the data structure (or in case of a hash never change the keys anymore -- values can change). I don't want to hijack an enhancement but let's do this :)</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422352013-10-03T07:34:57Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Ok I have been talked out of the allowing changing contents of the literal. Without guaranteeing the values never change then it is very limited in when you can do most of the "good" optimizations. They can be done but generally only in the case where you are doing a pure-literal sort of code. Once you assign the literal to a variable all bets are off (unless you can constant propagate it). I rescind my idea :)</p>
<p>I need to think more about frozen literals and come back to this issue :(</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=422492013-10-03T19:39:09Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>naruse: Within what group do I need to get consensus? All ruby-core committers?</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=423782013-10-10T00:03:01Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>=begin<br>
Note that if <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Use String#freeze and compiler tricks to replace "str"f suffix (Closed)" href="https://bugs.ruby-lang.org/issues/8992">#8992</a> is accepted, the same optimization could apply to arrays and hashes. In other words:</p>
<p>[].freeze<br>
{}.freeze<br>
[:foo, 1, true].freeze<br>
{:foo => 1}.freeze</p>
<p>could all be optimized to return the same object everywhere, every time. For arrays and hashes with non-literal elements, they would not enforce elements being frozen...but neither does .freeze.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=425472013-10-22T21:20:56Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>FWIW, I added <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Add String#f method as shortcut for #freeze (Open)" href="https://bugs.ruby-lang.org/issues/9043">#9043</a> that proposes an #f method added to String that would be a shortcut for #freeze. That might make this optimization harder, since we don't necessarily want to add #f at a global level.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=428892013-11-13T07:32:19Zheadius (Charles Nutter)headius@headius.com
<ul><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li><li><strong>Target version</strong> changed from <i>2.6</i> to <i>2.1.0</i></li></ul><p><a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Use String#freeze and compiler tricks to replace "str"f suffix (Closed)" href="https://bugs.ruby-lang.org/issues/8992">#8992</a> landed changes to optimize String#freeze, and <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Add String#f method as shortcut for #freeze (Open)" href="https://bugs.ruby-lang.org/issues/9043">#9043</a> deals with the possibility of adding a shortcut String#f method.</p>
<p>I believe this issue will now decide:</p>
<ul>
<li>Should the compiler optimize some form (or all forms) of literal Array and Hash immediately followed by #frozen?</li>
<li>What forms should lead to optimization?</li>
<li>Should #f method be added to Array and Hash as well?</li>
</ul>
<p>I think we need matz to weigh in here. My opinion:</p>
<ul>
<li>Compilers should be allowed to optimize .freeze to return the same object when appropriate (i.e. when the elements contained are themselves idempotent). Other cases cannot be optimized.</li>
<li>A shortcut #f method on Array and Hash would reduce the ugly factor when creating pre-frozen arrays and hashes, and might be nice to have for the same reasons as String#f.</li>
</ul>
<p>Marking for 2.1 and assigning to matz to get a verdict.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=428902013-11-13T07:33:29ZAnonymous
<ul></ul><p>My personal opinion on extending optimized #freeze to other literals is that it should be up to each implementation to decide on.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=428962013-11-13T09:29:18Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>"charliesome (Charlie Somerville)" <a href="mailto:charliesome@ruby-lang.org" class="email">charliesome@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>My personal opinion on extending optimized #freeze to other literals<br>
is that it should be up to each implementation to decide on.</p>
</blockquote>
<p>I agree. If an optimization can be accomplished without breaking<br>
compatibility of common/reasonable code, implementations should be free<br>
to optimize as they wish.</p> Ruby master - Feature #8909: Expand "f" frozen suffix to literal arrays and hasheshttps://bugs.ruby-lang.org/issues/8909?journal_id=436542013-12-14T08:43:30Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Rejected</i></li></ul><p>"f" suffix has been removed from string literals.</p>