[#122973] [PATCH] Add Gem.default_install — Felipe Contreras via ruby-core <ruby-core@...>
We need a way to enable user installs by default so that tools like
3 messages
2025/08/17
[ruby-core:122944] [Ruby Feature#20205] Enable `frozen_string_literal` by default
From:
janosch-x via ruby-core <ruby-core@...>
Date:
2025-08-10 20:57:04 UTC
List:
ruby-core #122944
Issue #20205 has been updated by janosch-x (Janosch M=FCller). byroot (Jean Boussier) wrote in #note-73: > it probably doesn't make a huge difference, but your regexp is a bit too = strict It probably makes even less of a difference, but magic comments are also in= dentable, case-insensitive, and can be [grouped in one line](https://github= .com/ruby/ruby/blob/2a6345e957c01f4495323723c7a3d7ac0d4ac339/doc/syntax/com= ments.rdoc?plain=3D1#L56-L60), so *maybe* ```ruby /^\s*#\s*(-\*-(?:.*;)*\s*)?frozen[-_]string[-_]literal:\s*true(?(1)\s*(?:;.= *)*-\*-)\s*$/i ``` ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205#change-114249 * Author: byroot (Jean Boussier) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- ### 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 -- [email protected] To unsubscribe send an email to [email protected] ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub= y-lang.org/
