https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112013-10-02T11:03:12ZRuby Issue Tracking SystemRuby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=421902013-10-02T11:03:12Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p><a href="https://github.com/nobu/ruby/tree/frozen_string_pragma" class="external">https://github.com/nobu/ruby/tree/frozen_string_pragma</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=421932013-10-02T12:41:09Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>coupled with this I strongly feel we need a more usable way of using the deduping elsewhere.</p>
<p>Currently string#freeze will only affect the current string. If we had a string#frozen we could have it return a deduped frozen copy. From memory profiling the largest leak in ruby gems is strings that really should be duduped using a mechanism like it.</p>
<p>raised a separate issue on this: <a href="http://bugs.ruby-lang.org/issues/8977" class="external">http://bugs.ruby-lang.org/issues/8977</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=421942013-10-02T13:18:21Zsam.saffron (Sam Saffron)sam.saffron@gmail.com
<ul></ul><p>Can we also have a global switch to enable this everywhere (for debugging), it can make it simple to isolate the spots where it would fall over.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=421952013-10-02T13:23:20Zko1 (Koichi Sasada)
<ul></ul><p>(2013/10/02 13:18), sam.saffron (Sam Saffron) wrote:</p>
<blockquote>
<p>Can we also have a global switch to enable this everywhere (for debugging), it can make it simple to isolate the spots where it would fall over.</p>
</blockquote>
<p>+1. It should be another ticket.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422062013-10-02T15:08:47Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>There are several problems for f-suffix:</p>
<ul>
<li>The notation is ugly.</li>
</ul>
</blockquote>
<p>I forgot to mention Akira Matsuda's presentation at RubyShift 2013:<br>
<a href="http://sssslide.com/speakerdeck.com/a_matsuda/rails-engines-from-the-bottom-up" class="external">http://sssslide.com/speakerdeck.com/a_matsuda/rails-engines-from-the-bottom-up</a><br>
(The presentation shows code snippets with f-suffix extensively.)</p>
<p>He said that the response of audience for f-suffix was negative.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422072013-10-02T15:18:02ZAnonymous
<ul></ul><blockquote>
<p>I forgot to mention Akira Matsuda's presentation at RubyShift 2013:<br>
<a href="http://sssslide.com/speakerdeck.com/a_matsuda/rails-engines-from-the-bottom-up" class="external">http://sssslide.com/speakerdeck.com/a_matsuda/rails-engines-from-the-bottom-up</a><br>
(The presentation shows code snippets with f-suffix extensively.)</p>
<p>He said that the response of audience for f-suffix was negative.</p>
</blockquote>
<p>To be fair, you wouldn't really use f-suffix strings in all the places they were used in the presentation. They're only really useful in tight loops, or in code where aesthetics does not matter (eg. code generated from ERB).</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422102013-10-02T21:18:15Zsobrinho (Gabriel Sobrinho)gabriel.sobrinho@gmail.com
<ul></ul><p>Maybe I'm too late but why not use the same object when calling String#freeze?</p>
<p>I mean, currently this:</p>
<blockquote>
<p>"something".freeze.object_id<br>
=> 70273877530260<br>
"something".freeze.object_id<br>
=> 70273877536840</p>
</blockquote>
<p>And change the compiler to do this:</p>
<blockquote>
<p>"something".freeze.object_id<br>
=> 70273877530260<br>
"something".freeze.object_id<br>
=> 70273877530260</p>
</blockquote>
<p>Not sure about the work that need to be done and even if it's possible but it would maintain the syntax compatibility with legacy versions of ruby.</p>
<p>I'm not against the "something"f syntax, regardless it's really strange for the ruby idiom, I'm concerned about libraries that needs to run on legacy rubies.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422152013-10-02T23:36:03Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>I think having a pragma at the top of the file will be much more error prone than the f-syntax. As a file grows, the ability to notice you are in a frozen string file goes down. It would have been great if Ruby had started immutable strings by default but that ship has sailed, I think having some files be immutable will be confusing.</p>
<p>Are we sure we cannot find a nicer syntax for frozen strings: %f{hello, I am frozen}?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422182013-10-03T01:38:32Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I agree with Tom here. I think it's going to be almost useless to have a full-file "freeze-string" directive.</p>
<ul>
<li>
<p>From file to file, the meaning of a literal string would change. This would be confusing for everyone dealing with a project. They'd get frozen string errors in one file and not in another for exactly the same code.</p>
</li>
<li>
<p>Users would be forced to create new mutable strings with String.new. There would be no other way. So in one file you could create a new mutable string with "" and in another you'd have to use String.new.</p>
</li>
</ul>
<p>It would be a very bad idea to have a directive that completely changes the meaning of code from one file to another.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422212013-10-03T02:26:59Zbrixen (Brian Shirai)brixen@gmail.com
<ul></ul><blockquote>
<p>It would be a very bad idea to have a directive that completely changes the meaning of code from one file to another.</p>
</blockquote>
<p>For consistency sake, it should be noted that, in fact, this is exactly what the existing encoding pragma does, and it's also the express purpose of refinements.</p>
<p>Hence, a more nuanced argument than this broad stroke of "very bad idea" may be needed.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422232013-10-03T02:36:18Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>brixen (Brian Shirai) wrote:</p>
<blockquote>
<p>For consistency sake, it should be noted that, in fact, this is exactly what the existing encoding pragma does, and it's also the express purpose of refinements.</p>
</blockquote>
<p>The encoding directive changes the interpretation of the bytes within strings, but does not change their behavior. If m17n is working properly, you may never even see a difference in code, since even strings with different encodings can be negotiated into combining, matching regexp, and converting to other encodings.</p>
<p>Refinements change the meaning of code within a lexical scope...not within an entire file (unless it is the file's scope that is being refined). This is more analogous to instance_eval on a block, which changes what "self" methods are called against. You are correct that they do change the meaning of code within their scope, but whether that's a good feature or not is beyond the scope of this discussion. I do not particularly like refinements.</p>
<p>A frozen string directive would actually change the behavior of the strings in that file, making operations that worked before fail to work under the directive. Encoding does not make some methods on string start to raise errors, except where you may have differing encodings (which can happen without an encoding directive too).</p>
<blockquote>
<p>Hence, a more nuanced argument than this broad stroke of "very bad idea" may be needed.</p>
</blockquote>
<p>I'm not sure this is the place to have a meta-argument about how to argue for or against this proposal. But since you suggest a more nuanced argument, I suggest you look at the original points in my comment that explain <em>why</em> it would be a bad idea.</p>
<p>Do you have any arguments to make for or against this proposal?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422242013-10-03T02:44:59Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Brian since I have been able to infer you dislike both M17n and refinements that you agree with Charlie and I that this particular pragma might not be an idea you endorse? Perhaps you can elucidate a better argument against it?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422402013-10-03T12:16:28Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>enebo (Thomas Enebo) wrote:</p>
<blockquote>
<p>I think having a pragma at the top of the file will be much more error prone than the f-syntax. As a file grows, the ability to notice you are in a frozen string file goes down. It would have been great if Ruby had started immutable strings by default but that ship has sailed, I think having some files be immutable will be confusing.</p>
</blockquote>
<p>Enhance your IDE.</p>
<blockquote>
<p>Are we sure we cannot find a nicer syntax for frozen strings: %f{hello, I am frozen}?</p>
</blockquote>
<p>Almost all of the idea to add new syntax break 2.0 compatibility, and it makes adoption of frozen strings slow.<br>
It is the motivation of this suggestion.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422432013-10-03T13:53:18Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>On 2013/10/03 2:27, brixen (Brian Shirai) wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a> has been updated by brixen (Brian Shirai).</p>
</blockquote>
<blockquote>
<blockquote>
<p>It would be a very bad idea to have a directive that completely changes the meaning of code from one file to another.</p>
</blockquote>
<p>For consistency sake, it should be noted that, in fact, this is exactly what the existing encoding pragma does,</p>
</blockquote>
<p>The reason why there is an encoding pragma, and why it's per file, is<br>
because text editors deal with one encoding per file. Doing something<br>
like an encoding pragma e.g. on a block basis would not work well<br>
together with editors.</p>
<p>I agree with Charles and others that a file-based directive isn't a good<br>
idea for frozen/fixed strings.</p>
<p>From a more general perspective, it feels to me that introducing all<br>
these frozen options will increase performance, but at the cost of<br>
programmer effort. That would be the case also e.g. for something like<br>
type hints,..., but that's not Ruby style.</p>
<p>Regards, Martin.</p>
<p>and it's also the express purpose of refinements.</p>
<blockquote>
<p>Hence, a more nuanced argument than this broad stroke of "very bad idea" may be needed.</p>
<hr>
<p>Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a>: file-scope freeze_string directive<br>
<a href="https://bugs.ruby-lang.org/issues/8976#change-42221" class="external">https://bugs.ruby-lang.org/issues/8976#change-42221</a></p>
<p>Author: akr (Akira Tanaka)<br>
Status: Open<br>
Priority: Normal<br>
Assignee:<br>
Category:<br>
Target version: current: 2.1.0</p>
</blockquote> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422512013-10-03T19:49:12Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>duerst (Martin Dürst) wrote:</p>
<blockquote>
<p>From a more general perspective, it feels to me that introducing all<br>
these frozen options will increase performance, but at the cost of<br>
programmer effort. That would be the case also e.g. for something like<br>
type hints,..., but that's not Ruby style.</p>
</blockquote>
<p>Personally, I think the more important benefit of having instantly-frozen literal strings, arrays, and hashes is for safer concurrency and data integrity.</p>
<ul>
<li>If I pass you a reference to a string, I can create that string frozen and be sure you don't modify it. Same goes for arrays and hashes.</li>
<li>If I am initializing a global array or hash that should never be modified, I can create it frozen immediately.</li>
</ul>
<p>Of course these can all be done by calling .freeze on the object as well, but creating immutable structures right away avoids any mistakes. And then the potential VM optimizations are a bonus on top of that.</p>
<p>But I stand by my opinion that a global pragma for frozen literal strings is a bad idea, because it makes all literal strings in the file start raising errors for half their methods, and it makes it impossible to copy/paste from one file to another without code potentially breaking.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422562013-10-03T23:51:04Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I am mildly in favour of it so +1</p>
<p>As it is compatible with older ruby I see little harm in it. But please don't forget proper documentation, if this is given the thumbs up by matz!</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422572013-10-04T00:10:25Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>enebo (Thomas Enebo) wrote:</p>
<blockquote>
<p>I think having a pragma at the top of the file will be much more error prone than the f-syntax. As a file grows, the ability to notice you are in a frozen string file goes down. It would have been great if Ruby had started immutable strings by default but that ship has sailed, I think having some files be immutable will be confusing.</p>
</blockquote>
<p>Enhance your IDE.</p>
</blockquote>
<p>It is an answer but one I think is not acceptable (obviously that is only my opinion).</p>
<blockquote>
<blockquote>
<p>Are we sure we cannot find a nicer syntax for frozen strings: %f{hello, I am frozen}?</p>
</blockquote>
<p>Almost all of the idea to add new syntax break 2.0 compatibility, and it makes adoption of frozen strings slow.<br>
It is the motivation of this suggestion.</p>
</blockquote>
<p>Yeah. ko1 talked to me yesterday about this. I have been trying to think of other ways to not break backwards compatibility and have not thought of anything.</p>
<p>It is possible to put out a PL to 2.0 to add the syntax but obviously a decision like that is a big one. Older 2.0 libraries will not be able to read it. OTOH, MRI has been periodically putting out security fixes so perhaps a syntax error to force an upgrade is not a bad thing?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=422582013-10-04T00:12:46Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>enebo (Thomas Enebo) wrote:</p>
<blockquote>
<p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>enebo (Thomas Enebo) wrote:</p>
<blockquote>
<p>I think having a pragma at the top of the file will be much more error prone than the f-syntax. As a file grows, the ability to notice you are in a frozen string file goes down. It would have been great if Ruby had started immutable strings by default but that ship has sailed, I think having some files be immutable will be confusing.</p>
</blockquote>
<p>Enhance your IDE.</p>
</blockquote>
<p>It is an answer but one I think is not acceptable (obviously that is only my opinion).</p>
<blockquote>
<blockquote>
<p>Are we sure we cannot find a nicer syntax for frozen strings: %f{hello, I am frozen}?</p>
</blockquote>
<p>Almost all of the idea to add new syntax break 2.0 compatibility, and it makes adoption of frozen strings slow.<br>
It is the motivation of this suggestion.</p>
</blockquote>
<p>Yeah. ko1 talked to me yesterday about this. I have been trying to think of other ways to not break backwards compatibility and have not thought of anything.</p>
<p>It is possible to put out a PL to 2.0 to add the syntax but obviously a decision like that is a big one. Older 2.0 libraries will not be able to read it. OTOH, MRI has been periodically putting out security fixes so perhaps a syntax error to force an upgrade is not a bad thing?</p>
</blockquote>
<p>Read "Older 2.0 libraries will not be able to read it" as "Older MRI 2.0 implementations will not be able to read libraries which use this new syntax."</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423122013-10-07T23:53:12Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/10/2 enebo (Thomas Enebo) <a href="mailto:tom.enebo@gmail.com" class="email">tom.enebo@gmail.com</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a> has been updated by enebo (Thomas Enebo).</p>
<p>I think having a pragma at the top of the file will be much more error prone than the f-syntax. As a file grows, the ability to notice you are in a frozen string file goes down. It would have been great if Ruby had started immutable strings by default but that ship has sailed, I think having some files be immutable will be confusing.</p>
</blockquote>
<h2>I think it is not a big problem because<br>
we don't need to aware the directive is exist or not if we use<br>
"..." to strings not modified and "...".dup to strings to be modified.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423232013-10-08T08:50:58Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>"...".dup looks too verbose to me.<br>
How about using "..." for a mutable string and '...' for an immutable?</p>
<p>I'm not so keen on a file-scope directive itself, though...</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423262013-10-08T09:29:15Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/10/8 mame (Yusuke Endoh) <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a> has been updated by mame (Yusuke Endoh).</p>
<p>"...".dup looks too verbose to me.<br>
How about using "..." for a mutable string and '...' for an immutable?</p>
</blockquote>
<p>I considered it at first.<br>
But we (at the meeting) abondoned it because<br>
we want to use escape sequences, such as \n, in immutable strings.</p>
<p>I wrote this concern in <a href="/issues/8976">[ruby-core:57574]</a> as follows.</p>
<h2>| Note that the directive effects all static string literals regardless of<br>
| single quotes, double quotes, %q-string, %qq-string and here documents.<br>
| The reason that the directive is effective not only single quotes is<br>
| we want to use escape sequences such as \n in frozen string literals.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423302013-10-08T16:03:20ZAnonymous
<ul></ul><p>"..."f might be mildly ugly, but is hard to beat.<br>
5 minutes of my thinking did not yield any better idea.<br>
I share mame's feeling abou the file-scope directive.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423882013-10-10T00:43:59Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>boris_stitnicky (Boris Stitnicky) wrote:</p>
<blockquote>
<p>"..."f might be mildly ugly, but is hard to beat.<br>
5 minutes of my thinking did not yield any better idea.<br>
I share mame's feeling abou the file-scope directive.</p>
</blockquote>
<p>I still don't like file-scope directive since it changes <em>behavior</em> rather than just <em>content</em>. In other words, a file that gains a frozen string directive suddenly creates strings that are only half functional.</p>
<p>See also <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://redmine.ruby-lang.org/issues/8992">#8992</a> that might address all issues by simply making the compiler and #freeze methods smarter.</p>
<ul>
<li>Compiler would see through "literal".freeze and do what "literal"f" does now.</li>
<li>String#freeze could be adapted to use the fstring cache internally, so all frozen strings would be interned (in the Java sense).</li>
<li>No new backward-incompatible syntax.</li>
<li>Easy expansion to other literal syntaxes like arrays and hashes.</li>
</ul>
<p>I think we need to kill off the "literal"f syntax and a file-scope directive is not the right way to do it.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=423922013-10-10T00:59:22Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>2013/10/10 headius (Charles Nutter) <a href="mailto:headius@headius.com" class="email">headius@headius.com</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a> has been updated by headius (Charles Nutter).</p>
<p>See also <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://redmine.ruby-lang.org/issues/8992">#8992</a> that might address all issues by simply making the compiler and #freeze methods smarter.</p>
<ul>
<li>Compiler would see through "literal".freeze and do what "literal"f" does now.</li>
<li>String#freeze could be adapted to use the fstring cache internally, so all frozen strings would be interned (in the Java sense).</li>
<li>No new backward-incompatible syntax.</li>
<li>Easy expansion to other literal syntaxes like arrays and hashes.</li>
</ul>
</blockquote>
<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://redmine.ruby-lang.org/issues/8992">#8992</a> doesn't address the problem follows.</p>
<h2>| * Need to modify for each string literal.<br>
| This is cumbersome.</h2>
<p>Tanaka Akira</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=424132013-10-10T18:33:39ZEregon (Benoit Daloze)
<ul></ul><p>akr (Akira Tanaka) wrote:</p>
<blockquote>
<p>2013/10/10 headius (Charles Nutter) <a href="mailto:headius@headius.com" class="email">headius@headius.com</a>:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a> has been updated by headius (Charles Nutter).</p>
<p>See also <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://redmine.ruby-lang.org/issues/8992">#8992</a> that might address all issues by simply making the compiler and #freeze methods smarter.</p>
<ul>
<li>Compiler would see through "literal".freeze and do what "literal"f" does now.</li>
<li>String#freeze could be adapted to use the fstring cache internally, so all frozen strings would be interned (in the Java sense).</li>
<li>No new backward-incompatible syntax.</li>
<li>Easy expansion to other literal syntaxes like arrays and hashes.</li>
</ul>
</blockquote>
<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://redmine.ruby-lang.org/issues/8992">#8992</a> doesn't address the problem follows.</p>
<h2>| * Need to modify for each string literal.<br>
| This is cumbersome.</h2>
<p>Tanaka Akira</p>
</blockquote>
<p>I think freezing these literals by adding ".freeze" to each of them is appropriate, these literals should already (in current version) be frozen to prevent any modification.</p>
<p>Changing semantics file-based is much too dangerous. And calling #dup just to have a mutable static literal String has no good meaning, it is just weird.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=447212014-01-30T04:50:00Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Target version</strong> changed from <i>2.1.0</i> to <i>2.2.0</i></li></ul> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=494902014-10-16T06:38:25Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Recent Eric Wong's effort reminds me this issue.</p>
<p>I still think this issue is worth to consider.</p>
<p>Ruby 2.1 changed the semantics of "...".freeze to avoid string allocation.<br>
It is not used extensively, I feel.</p>
<p>File scope directive provides a way to use frozen string literals with<br>
much fewer modification to programs.</p>
<p>Also, I think frozen string literals is a better programming style.<br>
It needs dup call ("...".dup) for string literals to be modified.<br>
It makes us to prevent unintentional modification and<br>
we can distinguish string literals to be modified or not, more easily.</p>
<p>I would like that future Ruby (Ruby 3.0?) will interpret string literals as frozen by default.<br>
This issue can be considered as a migration path.<br>
We can introduce file-scope directive now and change the default at future when<br>
most programs uses frozen string literals.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=494952014-10-16T08:01:53Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:akr@fsij.org" class="email">akr@fsij.org</a> wrote:</p>
<blockquote>
<p>Recent Eric Wong's effort reminds me this issue.</p>
<p>I still think this issue is worth to consider.</p>
<p>Ruby 2.1 changed the semantics of "...".freeze to avoid string allocation.<br>
It is not used extensively, I feel.</p>
</blockquote>
<p>Right, "...".freeze is too ugly IMHO. Ruby should stay beautiful :)</p>
<blockquote>
<p>File scope directive provides a way to use frozen string literals with<br>
much fewer modification to programs.</p>
<p>Also, I think frozen string literals is a better programming style.<br>
It needs dup call ("...".dup) for string literals to be modified.</p>
</blockquote>
<p>I also think needing to call "...".dup is ugly and will break much<br>
existing code[1].</p>
<blockquote>
<p>It makes us to prevent unintentional modification and<br>
we can distinguish string literals to be modified or not, more easily.</p>
</blockquote>
<p>My concern is optimizing Ruby for the typical script language users[2],<br>
not the (few) Rubyists who understand VM internals.</p>
<p>I prefer we continue to improve Ruby, transparently:</p>
<ul>
<li>2.1 (past) - { "str" => ... }, "str".freeze</li>
<li>2.2 (done) - h["str"] (= ...)</li>
<li>2.2 (planned) - .{gsub/sub/tr/tr_s}(["str"]|/../, "str"), ==, %,<br>
many more core (cfunc) methods</li>
</ul>
<p>All of the above are transparent to existing code.</p>
<blockquote>
<p>I would like that future Ruby (Ruby 3.0?) will interpret string<br>
literals as frozen by default.<br>
This issue can be considered as a migration path.<br>
We can introduce file-scope directive now and change the default at<br>
future when most programs uses frozen string literals.</p>
</blockquote>
<p>I am against this; especially as a default for 3.0[1]. File scope<br>
directives makes refactoring and reorganization of code more difficult:<br>
move a method to a new file and behavior changes.</p>
<p>I hope we can implement more optimization transparently in the compiler.<br>
For example; we should be able to optimize more cases:</p>
<pre><code> def foo(a, b)
a.gsub(/baz/, b)
end
foo(a, "lit") # no dup if `a' is a string
</code></pre>
<p>I think we can also use use (internal) C-API changes to mark cfuncs as<br>
taking const args. It would be useful for things like Hash#merge!, too;<br>
not just string literals.</p>
<p>[1] - Even for Ruby 3.0; I strongly favor maintaining backwards<br>
compatibility as much as possible in Ruby-land.<br>
1.8 -> 1.9 was very painful for some users (including myself)</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=496492014-10-26T20:50:56Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Eric Wong wrote:</p>
<blockquote>
<p>Right, "...".freeze is too ugly IMHO. Ruby should stay beautiful :)</p>
</blockquote>
<p>Agreed.</p>
<blockquote>
<p>I also think needing to call "...".dup is ugly and will break much<br>
existing code[1].</p>
</blockquote>
<p>I don't think "...".dup is ugly.</p>
<p>I agree changing the default breaks much existing code.<br>
So changing the default is long term goal.</p>
<blockquote>
<blockquote>
<p>It makes us to prevent unintentional modification and<br>
we can distinguish string literals to be modified or not, more easily.</p>
</blockquote>
<p>My concern is optimizing Ruby for the typical script language users[2],<br>
not the (few) Rubyists who understand VM internals.</p>
</blockquote>
<p>Unnecessary string duplications problem is easy to understand.<br>
I think there is possibility to change the users.</p>
<blockquote>
<p>I am against this; especially as a default for 3.0[1]. File scope<br>
directives makes refactoring and reorganization of code more difficult:<br>
move a method to a new file and behavior changes.</p>
</blockquote>
<p>There are many context dependency for refactoring and reorganization now.<br>
One more context dependency is not a big problem.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539002015-08-21T07:43:40Zmatsuda (Akira Matsuda)ronnie@dio.jp
<ul></ul><p>Let us bring this two-year-aged very well matured feature proposal back to the table!</p>
<p>I would like to propose again to put this magic comment for freezing String literals into next version of Ruby.</p>
<a name="motivation"></a>
<h2 >motivation<a href="#motivation" class="wiki-anchor">¶</a></h2>
<p>There are several reasons that we need this feature <strong>now</strong>:</p>
<p>(1) Freezing Strings is getting people's attraction recently, because people have been started realizing that they can somewhat improve their app performance by freezing Strings.<br>
Hence, we see so many "performance improvement" patches that add <code>.freeze</code> to String literals here and there for <a href="https://github.com/rails/rails/commit/5bb1d4d288d019e276335465d0389fd2f5246bfd" class="external">frameworks</a>, <a href="https://github.com/rails/sprockets/commit/8fc09576d21e37a51fd12284844c35d826c91c02" class="external">libraries</a>, and even for <a href="https://github.com/ruby/ruby/pull/996" class="external">ruby stdlibs</a>.<br>
These "performance improvement".freeze patches would certainly improve some micro-benchmark results, but at the same time inject code ugliness in exchange for the speed.<br>
This apparently is a wrong approach. This is not a Ruby way. Ruby code must be kept beautiful.</p>
<p>(2) While discussing this freezing magic comment feature, Matz finally decided to make all String literals frozen by default (<a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Immutable String literal in Ruby 3 (Closed)" href="https://redmine.ruby-lang.org/issues/11473">#11473</a>).<br>
Having a magic comment switch per file would be a very good transition path to the coming big change in Ruby 3.</p>
<a name="the-magic-comment"></a>
<h2 >the magic comment<a href="#the-magic-comment" class="wiki-anchor">¶</a></h2>
<p>We chose this at the meeting.</p>
<pre><code># frozen_string_literal: true
</code></pre>
<a name="command-line-option"></a>
<h2 >command line option<a href="#command-line-option" class="wiki-anchor">¶</a></h2>
<p>A command line option switch for "ruby 3 mode" will also be added.<br>
If the option and the magic comment conflicts, the magic comment should win.</p>
<a name="creating-a-String-with-an-Encoding"></a>
<h2 >creating a String with an Encoding<a href="#creating-a-String-with-an-Encoding" class="wiki-anchor">¶</a></h2>
<p>While investigating ruby code in the stdlib, we found that in most cases mutating literal Strings happens in this form</p>
<pre><code>"".force_encoding(Encoding::ASCII_8BIT)
</code></pre>
<p>so we decided to introduce a new String costructor taking Encoding via kwarg as follows:</p>
<pre><code>String.new("", encoding: Encoding::ASCII_8BIT)
</code></pre>
<a name="current-status"></a>
<h2 >current status<a href="#current-status" class="wiki-anchor">¶</a></h2>
<p>Matz already accepted this proposal at the developer meeting in Tokyo yesterday, so this feature will be put into 2.3 unless we see any strong objection here.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539182015-08-21T14:50:54Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul></ul><p>I don't think the magic comment approach for freezing string literals is a good idea. For ruby libraries that are maintained, the maintainers will change their code so that they work when string literals are frozen by default (in ruby 3). For ruby libraries that are not maintained, the magic comment will not be added.</p>
<p>I am strongly in favor of freezing string literals by default in ruby 3. Most of the objections I've read against freezing string literals by default are regarding breaking of unmaintained gems. I think all ruby needs is a command line flag (e.g. --freeze-string-literals=no|yes) or environment variable (e.g. RUBY_FREEZE_STRING_LITERALS=0|1) that sets whether string literals should be frozen by default.</p>
<p>With the command line flag or environment variable, you can test in ruby 2.3 that your code will work in ruby 3. In ruby 3, if you are using a library/app that doesn't work with frozen string literals, you can turn it off. Turning off frozen string literals in ruby 3 will make things work, but hurt performance for the entire application, which will give people a reason to fix the code. If you add the ability for per-file magic comments, it will encourage people not to make their code work with frozen string literals, and it will make it harder to reason about code that uses string literals, since you'll have to check for a magic comment every time.</p>
<p>The only reason I can think of to support a magic comment for frozen string literals is if the maintainer of a library did not know how to make their library work when string literals are frozen by default. They could then use a magic comment and sweep the problem under the rug. Is that something we want to encourage?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539382015-08-21T22:18:05Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Jeremy Evans wrote:</p>
<blockquote>
<p>I don't think the magic comment approach for freezing string literals is a good idea. For ruby libraries that are maintained, the maintainers will change their code so that they work when string literals are frozen by default (in ruby 3). For ruby libraries that are not maintained, the magic comment will not be added.</p>
<p>I am strongly in favor of freezing string literals by default in ruby 3. Most of the objections I've read against freezing string literals by default are regarding breaking of unmaintained gems. I think all ruby needs is a command line flag (e.g. --freeze-string-literals=no|yes) or environment variable (e.g. RUBY_FREEZE_STRING_LITERALS=0|1) that sets whether string literals should be frozen by default.</p>
</blockquote>
<p>I think chaning the default behavior without migration path is too big pain.</p>
<p>A command line option, --enable-frozen-string-literal, is also planned at the developper meeting DevelopersMeeting20150820Japan.<br>
<a href="https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20150820Japan" class="external">https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20150820Japan</a><br>
<a href="https://docs.google.com/document/d/1e00tTj8ix2ofS8H2RiIMUhr39bABSc7AL0vk4KbtSF4/pub" class="external">https://docs.google.com/document/d/1e00tTj8ix2ofS8H2RiIMUhr39bABSc7AL0vk4KbtSF4/pub</a></p>
<p>Of course, its companion, --disable-frozen-string-literal, will be available too.</p>
<blockquote>
<p>With the command line flag or environment variable, you can test in ruby 2.3 that your code will work in ruby 3. In ruby 3, if you are using a library/app that doesn't work with frozen string literals, you can turn it off. Turning off frozen string literals in ruby 3 will make things work, but hurt performance for the entire application, which will give people a reason to fix the code. If you add the ability for per-file magic comments, it will encourage people not to make their code work with frozen string literals, and it will make it harder to reason about code that uses string literals, since you'll have to check for a magic comment every time.</p>
<p>The only reason I can think of to support a magic comment for frozen string literals is if the maintainer of a library did not know how to make their library work when string literals are frozen by default. They could then use a magic comment and sweep the problem under the rug. Is that something we want to encourage?</p>
</blockquote>
<p>file-scope directive enables us to update libraries incrementally.</p>
<p>We can't udpate all library at once.<br>
There are too many libraries and authors.<br>
Some libraries will be updated soon and other libraries don't.</p>
<p>We can obtain performance benefit from updated libraries.<br>
This encourage library update with smaller pain.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539472015-08-22T00:06:27Zcolindkelley (Colin Kelley)colin@invoca.com
<ul></ul><p>Akira Tanaka wrote:</p>
<blockquote>
<p>We can't update all libraries at once.<br>
There are too many libraries and authors.<br>
Some libraries will be updated soon and other libraries don't.</p>
</blockquote>
<p>I completely concur. We will need to work through many projects and libraries and gems to make this change. The comment directive is perfect for that because we can mark files/projects/gems that have been converted and tested while not disrupting others. This is exactly how we managed the transition to utf-8 and that went very smoothly.</p>
<blockquote>
<p>We can obtain performance benefit from updated libraries.</p>
</blockquote>
<p>Yes, we want the benefit sooner than Ruby 3.0, and we want to make the transition over time, before 3.0 becomes mainstream. Just like with utf-8.</p>
<p>Also, here is a command line gem to automatically add the magic comment to the .rb files in the current folder: <a href="https://github.com/Invoca/magic_frozen_string_literal" class="external">https://github.com/Invoca/magic_frozen_string_literal</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539482015-08-22T01:22:43Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul></ul><p>Colin Kelley wrote:</p>
<blockquote>
<p>Akira Tanaka wrote:</p>
<blockquote>
<p>We can't update all libraries at once.<br>
There are too many libraries and authors.<br>
Some libraries will be updated soon and other libraries don't.</p>
</blockquote>
<p>I completely concur. We will need to work through many projects and libraries and gems to make this change. The comment directive is perfect for that because we can mark files/projects/gems that have been converted and tested while not disrupting others. This is exactly how we managed the transition to utf-8 and that went very smoothly.</p>
</blockquote>
<p>Adding support for this magic comment will ensure that this problem will remain a problem far in the future. We should encourage people to fix the problem, not sweep the problem under the rug.</p>
<p>This is not like the encoding magic comment, which is necessary because the ruby source file could be in any encoding. In general, frozen string literal issues are easy to fix, unlike encoding issues. I'd guess that 80% of exceptions caused by this change will be on the line after the string literal.</p>
<p>No library should be mutating a string they don't own as a side effect, and this change will make it much easier to detect libraries that do. Adding a magic comment to such a library will make it more likely that the problem isn't discovered even after ruby 3.0 is released. We should not encourage behavior that will hide bugs.</p>
<p>Any time spent adding magic comments to existing libraries would be better spent just making sure that libraries work with frozen string literals. Assuming we have at least 2 years between 2.3 and 3.0, that should be enough time to test gems for compatibility with --enable-frozen-string-literal before such behavior becomes the default.</p>
<p>It needs to be painful to use libraries that don't support frozen string literals, in order to encourage people to fix those libraries. For those people who must use libraries that still don't support frozen string literals when ruby 3 is released, they can use --disable-frozen-string-literals and be no worse off than they are now.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539502015-08-22T07:01:51Zfunny_falcon (Yura Sokolov)funny.falcon@gmail.com
<ul></ul><p>New constructor is a good thing.<br>
But it is better to allow construction</p>
<pre><code>"".b
</code></pre>
<p>to be mutable string. <code>"".force_encoding(Encoding::ASCII_8BIT)</code> is used for compatibility with Ruby 1.9.3 (cause <code>"".b</code> were not backported :( )</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539582015-08-22T21:55:18Zwanabe (_ wanabe)s.wanabe@gmail.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/11473">Feature #11473</a>: Immutable String literal in Ruby 3</i> added</li></ul> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539612015-08-23T02:38:58Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><blockquote>
<p>It needs to be painful to use libraries that don't support frozen string literals, in order to encourage people to fix those libraries. For those people who must use libraries that still don't support frozen string literals when ruby 3 is released, they can use --disable-frozen-string-literals and be no worse off than they are now.</p>
</blockquote>
<p>I don't think it should be painful.<br>
The changing default at Ruby 3.0 is big pain.<br>
So, we should mitigate the pain.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539932015-08-25T12:10:19Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Akira Matsuda wrote:</p>
<blockquote>
<p>Hence, we see so many "performance improvement" patches that add <code>.freeze</code> to String literals here and there for <a href="https://github.com/rails/rails/commit/5bb1d4d288d019e276335465d0389fd2f5246bfd" class="external">frameworks</a>, <a href="https://github.com/rails/sprockets/commit/8fc09576d21e37a51fd12284844c35d826c91c02" class="external">libraries</a>, and even for <a href="https://github.com/ruby/ruby/pull/996" class="external">ruby stdlibs</a>.</p>
</blockquote>
<p>I'm interested in the actual effect of this feature. How many times faster will Rails run actually? Anyone measured?</p>
<p><a href="https://github.com/rails/rails/commit/5bb1d4d288d019e276335465d0389fd2f5246bfd" class="external">https://github.com/rails/rails/commit/5bb1d4d288d019e276335465d0389fd2f5246bfd</a></p>
<p>This committer seemed to perform only micro benchmark. Was there any reason why he didn't measure the actual time?</p>
<blockquote>
<p>0.4530373333993266 miliseconds saved per request</p>
</blockquote>
<blockquote>
<p>So we're shaving off 1 second of execution time for every 220 requests.</p>
</blockquote>
<p>Calculation looks wrong. Correctly, 1 second per 2200 requests?</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@ruby-lang.org" class="email">mame@ruby-lang.org</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=539982015-08-25T16:30:14Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Yusuke Endoh wrote:</p>
<blockquote>
<p>I'm interested in the actual effect of this feature. How many times faster will Rails run actually? Anyone measured?</p>
</blockquote>
<p>I did.</p>
<p>Experimental overview:</p>
<ul>
<li>I used <a href="https://github.com/akr/ruby/tree/frozen-string" class="external">akr's "immutable by default" branch</a>
</li>
<li>I executed:
<ul>
<li><code>gem install rails</code></li>
<li><code>rails new scaffold-test</code></li>
<li><code>rails s</code></li>
<li>open "Welcome aboard" page</li>
<li><code>ab -u 1000 -c 100 http://localhost:3000</code></li>
</ul>
</li>
<li>I compared it with 2.2.1p85 (released version)</li>
<li>Whenever "<code>can't modify frozen String</code>" exception is raised, I created and applied a very ad-hoc fix. I didn't count the fixes precisely, but I think about 50 fixes are needed. (rdoc, bundler, and gem install sqlite3, required many fixes.)</li>
</ul>
<p>Results: Requests per second</p>
<ul>
<li>immutable by default branch: 167.14 [#/sec]</li>
<li>2.2.1p85: 168.42 [#/sec]</li>
</ul>
<p>I tried a few times, but I couldn't see any difference.</p>
<p>Note:</p>
<ul>
<li>The current source of Rails already includes many <code>.freeze</code> literals. So there may be little room for improvement by this feature. The same experiment with removing all <code>.freeze</code> might be valuable.</li>
<li>I don't know how meaningful it is to measure the "requests per second" of "Welcome aboard" page on WEBrick.</li>
<li>My fixes for "<code>can't modify frozen String</code>" is really ad-hoc; they may break something.</li>
<li>Sorry, I didn't record my fixes, so I cannot provide the sufficient information for replication. But I could perform this experiment in a few hours, so I think it is not so difficult for other people to replicate this experiment. (I'm not familiar with Rails. Actually I used Rails for the first time in about 8 years.)</li>
</ul>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@ruby-lang.org" class="email">mame@ruby-lang.org</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=540222015-08-28T01:36:38Zrafaelfranca (Rafael França)rafael@franca.dev
<ul></ul><p>Here you can see more information about the actual effect of frozen string on Ruby on Rails <a href="https://github.com/rails/rails/pull/21057" class="external">https://github.com/rails/rails/pull/21057</a>. It is 11% in a relative small application, in big applications this improvement can be bigger.</p>
<blockquote>
<p>I don't know how meaningful it is to measure the "requests per second" of "Welcome aboard" page on WEBrick.</p>
</blockquote>
<p>You are hitting a static page so it will not even hit the default Rails stack. You could try to hit the <code>scaffold-test</code> URL to get more meaningful results.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=542562015-09-22T06:43:32Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Assignee</strong> set to <i>akr (Akira Tanaka)</i></li></ul><p>It seems (for me) frozen string literals are good trade-off between current Ruby (every string is mutable) and immutable strings.<br>
If all strings are immutable, it introduces huge incompatibility. With frozen string literals, we may be able to find more errors earlier.<br>
Or maybe some Ruby programs run faster.</p>
<p>But first we have to prove if this is a good idea. So my plan is to introduce frozen-string-literal magic comment (pragma) for 2.3, and see whether it works well or not. If it works well, I'd love to make string literals frozen by default in Ruby3. But if not, frozen-string-literal ends as an experiment.</p>
<p>Matz.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=542572015-09-22T09:33:45Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/54257/diff?detail_id=38988">diff</a>)</li><li><strong>Assignee</strong> deleted (<del><i>akr (Akira Tanaka)</i></del>)</li></ul><p><a href="https://github.com/nobu/ruby/tree/feature/pragma-frozen_string" class="external">https://github.com/nobu/ruby/tree/feature/pragma-frozen_string</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=542582015-09-22T10:46:44Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p><a href="https://github.com/nobu/ruby/tree/feature/pragma-frozen_string" class="external">https://github.com/nobu/ruby/tree/feature/pragma-frozen_string</a></p>
</blockquote>
<p>Great. It works fine.</p>
<pre><code>% ./ruby -e '# -*- frozen_string_literal: true -*-
p "foo".frozen?'
true
</code></pre>
<p>Would you please implement the proposed command line options,<br>
--{enable,disable}-frozen-string-literal ?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=542862015-09-27T06:44:28Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset r51953.</p>
<hr>
<p>fronzen-string-literal pragma</p>
<ul>
<li>compile.c (iseq_compile_each): override compile option by option<br>
given by pragma.</li>
<li>iseq.c (rb_iseq_make_compile_option): extract a function to<br>
overwrite rb_compile_option_t.</li>
<li>parse.y (parser_set_compile_option_flag): introduce pragma to<br>
override compile options.</li>
<li>parse.y (magic_comments): new pragma "fronzen-string-literal".<br>
[Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a>]</li>
</ul> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543422015-10-03T03:11:07Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Open</i></li></ul><p>Akira Matsuda wrote:</p>
<blockquote>
<a name="the-magic-comment"></a>
<h2 >the magic comment<a href="#the-magic-comment" class="wiki-anchor">¶</a></h2>
<p>We chose this at the meeting.</p>
<pre><code># frozen_string_literal: true
</code></pre>
</blockquote>
<p>This does not work correctly. The current implementation needs <code>-*-</code>.</p>
<pre><code># -*- frozen_string_literal: true -*-
</code></pre>
<p>Since <code>encoding</code> magic comments do not require <code>-*-</code>, I don't expect frozen_string_literal requires it.</p>
<p>If users write <code># frozen_string_literal: true</code> (in fact it make no effect) and see the code to work, she/he will misunderstand that no change is required. It is dangerous.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@ruby-lang.org" class="email">mame@ruby-lang.org</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543432015-10-03T05:59:35Zakr (Akira Tanaka)akr@fsij.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Yusuke Endoh wrote:</p>
<blockquote>
<p>Since <code>encoding</code> magic comments do not require <code>-*-</code>, I don't expect frozen_string_literal requires it.</p>
<p>If users write <code># frozen_string_literal: true</code> (in fact it make no effect) and see the code to work, she/he will misunderstand that no change is required. It is dangerous.</p>
</blockquote>
<p>I also surprised that.</p>
<p>However, I, you and Richard Schneeman find -*- correctly.</p>
<p>Richard Schneeman sent a patch for pathname.rb at<br>
<a href="https://bugs.ruby-lang.org/issues/11375#note-13" class="external">https://bugs.ruby-lang.org/issues/11375#note-13</a></p>
<p>So, currently I think it is acceptable.</p>
<p>Anyway it is orthogonal to frozen_string_literal itself.<br>
Please open another ticket if you think it is really a problem.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543442015-10-03T10:42:35Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Open</i></li><li><strong>Assignee</strong> set to <i>nobu (Nobuyoshi Nakada)</i></li></ul><blockquote>
<p>Anyway it is orthogonal to frozen_string_literal itself.</p>
</blockquote>
<p>I do NOT think so.</p>
<p>The current problem I concern is that "frozen_string_literal" requires <code>-*-</code>. This feature is the key test that decides Ruby's feature. If people fail to use this feature, it will lead to the wrong decision. And it is dangerous at least in the current situation, because people are only familiar with "encoding" magic comment that does not require <code>-*-</code>.</p>
<p>I do NOT intend to discuss the format of magic comment in general. I personally prefer no <code>-*-</code>. But it is just my preference. I don't feel a danger or problem, at least currently, because there is no other important kind of magic comments. (I don't think that warn_indent is critical.)</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@ruby-lang.org" class="email">mame@ruby-lang.org</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543452015-10-03T11:40:52Zkou (Kouhei Sutou)kou@cozmixng.org
<ul></ul><p>I object <code>-*- frozen_string_literal: true -*-</code> because it shows the following buffer on Emacs when I save or open the file.</p>
<pre><code class="text syntaxhl" data-language="text">The local variables in a.rb
contains values that may not be safe (*).
Do you want to apply it? You can type
y -- to apply the local variables list.
n -- to ignore the local variables list.
! -- to apply the local variables list, and permanently mark these
values (*) as safe (in the future, they will be set automatically.)
* flozen_string_literal : true
</code></pre>
<p><code>frozen_string_literal: true</code> doesn't show it.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543462015-10-03T16:12:32Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Kouhei Sutou wrote:</p>
<blockquote>
<p>I object <code>-*- frozen_string_literal: true -*-</code> because it shows the following buffer on Emacs when I save or open the file.</p>
</blockquote>
<p>Put another line before it.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543472015-10-04T05:42:31Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>I agree with Yusuke Endoh and Kouhei Sutou: requiring -*- creates unnecessary variation among directives. Also, putting another line before it (as Nobu suggests) to avoid problems in Emacs is counter to the idea that all these directives should be grouped at the start of the file.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543562015-10-05T05:55:15Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Sutou-san's objection apeal me.</p>
<p>I occur "File mode specification error: (void-variable ruby-font-lock-keywords)" with emacs.<br>
Nakada-san's workaround (another line before it) didn't help.</p>
<p>There is no problem with vim which is my favorite editor, though.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543612015-10-05T07:04:42Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>What line did you put?</p>
<p>Emacs opens this file fine.</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="c1">#</span>
<span class="c1"># -*- frozen-string-literal: true -*-</span>
<span class="nb">p</span> <span class="s2">""</span><span class="p">.</span><span class="nf">frozen?</span>
</code></pre> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543622015-10-05T07:14:28Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>What line did you put?</p>
<p>Emacs opens this file fine.</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="c1">#</span>
<span class="c1"># -*- frozen-string-literal: true -*-</span>
<span class="nb">p</span> <span class="s2">""</span><span class="p">.</span><span class="nf">frozen?</span>
</code></pre>
</blockquote>
<p>This file still shows "File mode specification error: (void-variable ruby-font-lock-keywords)" in minibuffer.</p>
<pre><code>boron% cat z.rb
#
# -*- frozen-string-literal: true -*-
p "".frozen?
boron% emacs -q z.rb
boron% emacs --version
GNU Emacs 21.4.1
Copyright (C) 2002 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
</code></pre> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543632015-10-05T13:10:27Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>21...<br>
Does ruby-mode.el work?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543642015-10-05T13:14:32Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>That is, "(void-variable ruby-font-lock-keywords)" means ruby-mode.el doesn't support your Emacs.<br>
It's irrelevant to frozen-string-literal at all.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543652015-10-05T13:23:43Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>I see.</p>
<p>The error is happen without -<em>- frozen-string-literal: true -</em>-.<br>
I understand that my emacs problem is not related to -*-.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543772015-10-06T15:08:27Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>Does nobu seriously require all Rubyists to write codes like this? ;-)</p>
<p><a href="https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443" class="external">https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443</a></p>
<p>Leave emacs aside, I still believe this magic comment must not require <code>-*-</code>. It is too error-prone.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@ruby-lang.org" class="email">mame@ruby-lang.org</a></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=543842015-10-07T11:13:46ZEregon (Benoit Daloze)
<ul></ul><p>Yusuke Endoh wrote:</p>
<blockquote>
<p>Does nobu seriously require all Rubyists to write codes like this? ;-)</p>
<p><a href="https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443" class="external">https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443</a></p>
<p>Leave emacs aside, I still believe this magic comment must not require <code>-*-</code>. It is too error-prone.</p>
</blockquote>
<p>Agreed, to me this is a fatal flaw of the current implementation of parsing the magic comment and it is very inconsistent.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544052015-10-09T06:06:25Zshugo (Shugo Maeda)
<ul></ul><p>In r52087, I've changed the behavior not to freeze dynamic string literals (e.g., "#{x}")<br>
because dynamic string literals don't literally represent strings.</p>
<p>Please give us your feedback if you have any objection.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544072015-10-09T15:52:30Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>What about <code>"#{'foo'}"</code>?</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544392015-10-13T09:06:04Zshugo (Shugo Maeda)
<ul></ul><p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>What about <code>"#{'foo'}"</code>?</p>
</blockquote>
<p><code>"#{'foo'}"</code> can be considered literal (or static), but there's still room for discussion about it.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544402015-10-13T10:03:39Zphluid61 (Matthew Kerwin)matthew@kerwin.net.au
<ul></ul><p>Shugo Maeda wrote:</p>
<blockquote>
<p>Nobuyoshi Nakada wrote:</p>
<blockquote>
<p>What about <code>"#{'foo'}"</code>?</p>
</blockquote>
<p><code>"#{'foo'}"</code> can be considered literal (or static), but there's still room for discussion about it.</p>
</blockquote>
<p>Another case is <code>"#{}foo"</code> -- if that is treated as a dynamic string, it could become an alternative idiom for <code>"foo".dup</code></p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544422015-10-13T10:39:14Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p><code>"#{}foo"</code> is different slightly, -- it is equivalent to <code>"#{nil.to_s}foo"</code> and depends on <code>NilClass#to_s</code>, so it can't be a static literal.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=544992015-10-21T02:57:22Zshugo (Shugo Maeda)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> changed from <i>nobu (Nobuyoshi Nakada)</i> to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>Benoit Daloze wrote:</p>
<blockquote>
<p>Yusuke Endoh wrote:</p>
<blockquote>
<p>Does nobu seriously require all Rubyists to write codes like this? ;-)</p>
<p><a href="https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443" class="external">https://github.com/ruby/ruby/commit/36ca18b84715dcc92a82ec4cbef6e83321640443</a></p>
<p>Leave emacs aside, I still believe this magic comment must not require <code>-*-</code>. It is too error-prone.</p>
</blockquote>
<p>Agreed, to me this is a fatal flaw of the current implementation of parsing the magic comment and it is very inconsistent.</p>
</blockquote>
<p>+1</p>
<p>This issue should be discussed at the developers meeting today, and Matz should desicde whether <code>-*-</code> should be required.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=545032015-10-21T09:34:32Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul><p>Applied in changeset r52208.</p>
<hr>
<p>parse.y: magic comment w/o indicators</p>
<ul>
<li>parse.y (parser_magic_comment): allow a sole magic comment without<br>
indicators, neither other non-space comments. [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a>]</li>
</ul> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=546702015-11-02T10:58:08Zko1 (Koichi Sasada)
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Open</i></li></ul><p>Quoted from<br>
log: <a href="https://docs.google.com/document/d/1axnQv1A2SdRExw--_RzXXJAPrRyvN7MCIB0WrKcZaSE/pub" class="external">https://docs.google.com/document/d/1axnQv1A2SdRExw--_RzXXJAPrRyvN7MCIB0WrKcZaSE/pub</a><br>
of <a href="https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20151021Japan" class="external">https://bugs.ruby-lang.org/projects/ruby/wiki/DevelopersMeeting20151021Japan</a></p>
<pre><code>Decide whether -*- should be required for frozen_string_literal magic comments [Feature #8976]
naruse: vim’s indicator is “vim: …” http://vim.wikia.com/wiki/Modeline_magic
nobu: should be have an indicator of pragrma.
matz: why?
nobu: to avoid misunderstanding with comments.
matz: nobody care about that.
nobu: line should not include any other information.
matz: i agree with it.
conclusion:
accept pragma without indicators
do not accept pragma in the comment (do not skip any words before pragma keywords)
matz: i don’t want to recommend indicators.
nobu: sould we remove indicators?
akr: should remain indicators to keep compatibility.
ko1: only coding pragma?
nobu: we have warn-indnent pragmra.
naruse: warn-indent is in 2010
nobu: i’ll make it to keep compatibility.
conclusion:
keep compatibility for current indicator (for any pragma)
naruse: should we put pragmas in one line? or multi-lines?
akr: there are possibilities to increase pragma, so that shold accept multi-lines.
matz: i do not care about multi-lines.
akr: people may want to write copyright early.
naruse: people may want to write a comment for pragmas
conclusion:
accept multi-lines at the beggining of programming.
accept comments between pragmas.
akr: how about dynamic strings “foo#{bar}baz”?
nobu: how about “#{‘baz’}”?
ko1: it is easy to understand all “...” is frozen. Shugo-san’s first comment is for “compatibility”.
matz: i agree to
matz: i have another idea +“...” -> mutable, -”...” -> immutable. it is more clean than “...”.freeze. how about that, instead of the magic comment? i don’t care about pull-requests, but care about the representation of source code.
akr: …
matz: I don’t like magic comment, so that I hesitate to introduce it.
a_matsuda: + and - seems string operation. << -”foo” can be seen as a here document.
matz: I understand. + and - is not good idea.
matz: another idea: make ‘’’foo’’’ frozen. incompatibility is negligible.
matz: yet another idea: make single quoted strings frozen. This is incompatible.
MISC:
akr: should we separate this topic to another ticket? this is “how to write a pragmra”.
ko1: we should describe syntax of “how to write pragmas”
matz: I don’t like pragmas but if it is required
ko1: this pragma is for experimental feature. if we decide to reject default frozen string literal, then you remove this pragma, or remain this pragma?
matz: i will remain it.
deep_freeze
→ traversal framework?
inspect に引数を渡したい
→ inspect2? not clean.
naruse: On 1.9 I tried to implement such logic, but I gave up and use Encoding.default_internal/Encoding.default_external
</code></pre>
<p>Maybe there are several incomprehensible sentences.<br>
Please ask that and continue to discuss.</p>
<p>Thanks,<br>
Koichi</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547052015-11-04T07:45:53Zshugo (Shugo Maeda)
<ul></ul><p>Koichi Sasada wrote:</p>
<blockquote>
<p>akr: how about dynamic strings “foo#{bar}baz”?<br>
nobu: how about “#{‘baz’}”?<br>
ko1: it is easy to understand all “...” is frozen. Shugo-san’s first comment is for “compatibility”.<br>
matz: i agree to</p>
</blockquote>
<p>It's not just for compatibility.</p>
<p>The original problem was that a new String object has to be allocated by a string literal<br>
for each evaluation. So I don't understand the reason why a dynamic string literal should<br>
be frozen in spite of the fact freezing dynamic strings can't reduce object allocation.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547062015-11-04T11:12:03Zakr (Akira Tanaka)akr@fsij.org
<ul></ul><p>Shugo Maeda wrote:</p>
<blockquote>
<p>It's not just for compatibility.</p>
<p>The original problem was that a new String object has to be allocated by a string literal<br>
for each evaluation. So I don't understand the reason why a dynamic string literal should<br>
be frozen in spite of the fact freezing dynamic strings can't reduce object allocation.</p>
</blockquote>
<p>It is not a big problem.<br>
We can reduce extra object allocation with "foo#{exp}bar".dup using an optimization similar for "foo".freeze.</p>
<p>I think the pragma and option name should explain the behavior.<br>
The name is "frozen-string-literal".<br>
So, basically, all string literal should return a frozen object.</p>
<p>We need an explanation if we introduce an exception.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547142015-11-05T03:08:31Zkosaki (Motohiro KOSAKI)kosaki.motohiro@gmail.com
<ul></ul><blockquote>
<p>Shugo Maeda wrote:</p>
<blockquote>
<p>It's not just for compatibility.</p>
<p>The original problem was that a new String object has to be allocated by a string literal<br>
for each evaluation. So I don't understand the reason why a dynamic string literal should<br>
be frozen in spite of the fact freezing dynamic strings can't reduce object allocation.</p>
</blockquote>
<p>It is not a big problem.<br>
We can reduce extra object allocation with "foo#{exp}bar".dup using an optimization similar for "foo".freeze.</p>
<p>I think the pragma and option name should explain the behavior.<br>
The name is "frozen-string-literal".<br>
So, basically, all string literal should return a frozen object.</p>
<p>We need an explanation if we introduce an exception.</p>
</blockquote>
<p>+1</p>
<p>Current explanation is too weak to make an exception, I think.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547622015-11-09T06:35:12Zko1 (Koichi Sasada)
<ul></ul><p>Discussion: <a href="https://docs.google.com/document/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub" class="external">https://docs.google.com/document/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub</a></p>
<p>Feel free to add your comments.</p> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547762015-11-09T08:32:55Zshugo (Shugo Maeda)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset r52501.</p>
<hr>
<ul>
<li>compile.c (iseq_compile_each): Dynamic string literals should be<br>
frozen.<br>
<a href="/issues/8976">[ruby-core:57574]</a> [Feature <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: file-scope freeze_string directive (Closed)" href="https://redmine.ruby-lang.org/issues/8976">#8976</a>]</li>
</ul> Ruby master - Feature #8976: file-scope freeze_string directivehttps://redmine.ruby-lang.org/issues/8976?journal_id=547802015-11-09T09:20:27Zshugo (Shugo Maeda)
<ul></ul><p>Koichi Sasada wrote:</p>
<blockquote>
<p>Discussion: <a href="https://docs.google.com/document/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub" class="external">https://docs.google.com/document/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub</a></p>
<p>Feel free to add your comments.</p>
</blockquote>
<p>I didn't mean to claim that <code>"#{exp}".dup</code> needs more object allocation, but to claim that<br>
<code>"#{exp}"</code> cannot be interned.<br>
Anyway, I agree with the conclusion and have reverted r52087.</p>