Misc #16047


Reconsider impact of frozen_string_literal on dynamic strings

Added by Dan0042 (Daniel DeLorme) about 3 years ago. Updated almost 2 years ago.



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]
This may be true, but at the expense of making it cumbersome to use. And freezing dynamic strings is useless (no-op) for memory optimization, but making it mutable again via "foo #{bar}".dup means we allocate two strings where only one was needed before.

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.

Related issues 1 (0 open1 closed)

Has duplicate Ruby master - Feature #17104: Do not freeze interpolated strings when using frozen-string-literalClosedEregon (Benoit Daloze)Actions

Also available in: Atom PDF