Issue #16047 has been updated by Dan0042 (Daniel DeLorme).



@shevegen, I didn't suggest what I would like to change because I was only looking for insight on people's real-world usage of frozen_string_literal and how it might compare to mine. That's why I put this under the Misc tracker and not Feature. But since you took the time to write such an extra-complete response I will try my best to answer your questions back.

> The rationale for introducing frozen_string_literal

Before frozen_string_literal, `"".freeze` was introduced as a memory optimization. Prior to ruby 2.1 it would just create a new string and freeze it, but from 2.1 on it would deduplicate it also. So everybody started using this for memory performance. This was seen as injecting code ugliness in exchange for speed and not the ruby way. At least [as explained here](https://bugs.ruby-lang.org/issues/8976#note-30) by @matsuda

I am interested in the claimed/perceived speedup. I had seen some benchmarks that claimed no difference in speed. And that made sense to me since deduplication is a memory optimization, not a significant CPU optimization.

Of course I can also choose to use `frozen_string_literal: false` (and I do), but the point that I was trying to make is that it doesn't have to be an either-or situation; we could have the **best of both worlds** if dynamic string literals were not frozen by the magic comment.


> The rationale for freezing all strings including dynamic was because it's easy to explain

[I got that rationale from here](https://docs.google.com/document/u/1/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub)

> And also completely useless for memory optimization.

What I meant here is that `"foo #{bar}"` allocates a string so there's no deduplication and no advantage to freezing; and `"foo #{bar}".dup` allocates two strings where only one should be needed. Of course everything else is a worthy optimization so saying "useless" was perhaps a bit too strong.



----------------------------------------
Misc #16047: Reconsider impact of frozen_string_literal on dynamic strings
https://bugs.ruby-lang.org/issues/16047#change-80409

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
The rationale for introducing `frozen_string_literal` was because rubyists were starting to litter their code with `"".freeze` for optimization, and it's ugly.

But by using frozen_string_literal we introduce the opposite problem: we must litter the code with `"".dup` in order to have mutable strings, and it's ugly.

The rationale for freezing all strings including dynamic was because it's [easy to explain]
(https://docs.google.com/document/u/1/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4PKp7NvMyQ/pub)
This may be true, but at the expense of making it cumbersome to use. And also completely useless for memory optimization.

In my personal experience using frozen_string_literal, I find that static strings are usually ok to freeze without changing anything else, but that freezing dynamic strings often create bugs that require `+""` or `"".dup` boilerplate to circumvent. So in the end I found myself stopping regular use of that feature, since it's more trouble than it's worth.

As such I'd like to ask other rubyists how has been their experience with **actually using** frozen_string_literal on a day-to-day basis; if my experience is unique or common. Thank you for sharing your thoughts.



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>