[ruby-core:116404] [Ruby master Feature#20205] Enable `frozen_string_literal` by default

Issue #20205 has been updated by duerst (Martin D=FCrst).





`frozen_string_literal` can lead to more efficient code, but it's also part=
 of a programming style (usually called functional programming). Functional=
 programming often leads to cleaner code, but it may require some additiona=
l programming effort. There's also a fundamental conflict between object-or=
iented programming (objects are generally mutable) and functional programmi=
ng, although Ruby is pretty good at integrating these concepts.



My main issue with this proposal is that I think it's probably the right th=
ing for most big code bases, but it may not be the right thing for quick-an=
d-dirty small scripts. And Ruby is used, and should continue to be usable, =
for both kinds of code.



Maybe what could help is a declaration on a higher level, e.g. per gem or s=
o rather than per source file. (That's just an idea, with many open questio=
ns: Where would the setting go? How would the interpreter pick it up? How w=
ould people become aware of it? ...)



----------------------------------------

Feature #20205: Enable `frozen_string_literal` by default

https://bugs.ruby-lang.org/issues/20205#change-106425



* Author: byroot (Jean Boussier)

* Status: Open

* Priority: Normal

----------------------------------------

### Context



The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as=
 far as I'm aware the plan was initially to make it the default for Ruby 3.=
0, but this plan was abandoned because it would be too much of a breaking c=
hange without any real further notice.



According to Matz, he still wishes to enable `frozen_string_literal` by def=
ault in the future, but a reasonable migration plan is required.=20



The main issue is backward compatibility, flipping the switch immediately w=
ould break a lot of code, so there must be some deprecation period.



The usual the path forward for this kind of change is to emit deprecation w=
arnings one of multiple versions in advance.



One example of that was the Ruby 2.7 keyword argument deprecation. It was q=
uite verbose, and some users were initially annoyed, but I think the commun=
ity pulled through it and I don't seem to hear much about it anymore.



So for frozen string literals, the first step would be to start warning whe=
n a string that would be frozen in the future is mutated.



### Deprecation Warning Implementation



I implemented a quick proof of concept with @etienne in https://github.com/=
Shopify/ruby/pull/549



In short:



- Files with `# frozen_string_literal: true` or `# frozen_string_literal: f=
alse` don't change in behavior at all.

- Files with no `# frozen_string_literal` comment are compiled to use `putc=
hilledstring` opcode instead of regular `putstring`.

- This opcode mark the string with a user flag, when these strings are muta=
ted, a warning is issued.



Currently the proof of concept issue the warning at the mutation location, =
which in some case can make locating where the string was allocated a bit h=
ard.



But it is possible to improve it so the message also include the location a=
t which the literal string was allocated, and learning from the keyword arg=
ument warning experience,

we can record which warnings were already issued to avoid spamming users wi=
th duplicated warnings.



As currently implemented, there is almost no overhead. If we modify the imp=
lementation to record the literal location,

we'd incur a small memory overhead for each literal string in a file withou=
t an explicit `frozen_string_literal` pragma.



But I believe we could do it in a way that has no overhead if `Warning[:dep=
recated] =3D false`.



### Timeline



The migration would happen in 3 steps, each step can potentially last multi=
ple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`.

I don't have a strong opinion on the pace.



- Release `R0`: introduce the deprecation warning (only if deprecation warn=
ings enabled).

- Release `R1`: make the deprecation warning show up regardless of verbosit=
y level.

- Release `R2`: make string literals frozen by default.



### Impact



Given that `rubocop` is quite popular in the community and it has enforced =
the usage of `# frozen_string_literal: true` for years now,

I suspect a large part of the actively maintained codebases in the wild wou=
ldn't see any warnings.



And with recent versions of `minitest` enabling deprecation warnings by def=
ault (and [potentially RSpec too](https://github.com/rspec/rspec-core/issue=
s/2867)),

the few that didn't migrate will likely be made compatible quickly.



The real problem of course are the less actively developed libraries and ap=
plications. For such cases, any codebase can remain compatible by setting `=
RUBYOPT=3D"--disable=3Dfrozen_string_literal"`,

and so even after `R2` release. The flag would never be removed any legacy =
codebase can continue upgrading Ruby without changing a single line of cod =
by just flipping this flag.



### Workflow for library maintainers



As a library maintainer, fixing the deprecation warnings can be as simple a=
s prepending `# frozen_string_literal: false` at the top of all their sourc=
e files, and this will keep working forever.



Alternatively they can of course make their code compatible with frozen str=
ing literals.



Code that is frozen string literal compatible doesn't need to explicitly de=
clare it. Only code that need it turned of need to do so.



### Workflow for application owners



For application owners, the workflow is the same than for libraries.



However if they depend on a gem that hasn't updated, or that they can't upg=
rade it, they can run their application with `RUBYOPT=3D"--disable=3Dfrozen=
_string_literal"` and it will keep working forever.



Any user running into an incompatibility issue can set `RUBYOPT=3D"--disabl=
e=3Dfrozen_string_literal"` forever, even in `4.x`, the only thing changing=
 is the default value.



And any application for which all dependencies have been made fully frozen =
string literal compatible can set `RUBYOPT=3D"--enable=3Dfrozen_string_lite=
ral"` and start immediately removing magic comment from their codebase.









--=20

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

 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/