From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EB74C1F405 for ; Wed, 24 Jan 2024 11:11:37 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=iQriI2N4; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=iO3qLjvc; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 2C9E481F30; Wed, 24 Jan 2024 11:11:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1706094691; bh=WCH3dOHeCwtCxGmMN29Bf5bsTbGgQPFYJzQji6hGYxE=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=iQriI2N4TeRNw5xNaYJRiZJYTKlHuLUAaOMrmPH42/eJLV0TILYa4A0CpYLmwSW72 b+MAauhflQLSu9kCNh70iOGjZ+irsZAUfIkrAHVwS1aSh+dw2F2WvuOm6Drd4PGrHr t1TswQCi9TAfJ8THJTj1hoFeKsaRqqut4QYB0ZTs= Received: from wrqvtvvn.outbound-mail.sendgrid.net (wrqvtvvn.outbound-mail.sendgrid.net [149.72.120.130]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 9335581F0A for ; Wed, 24 Jan 2024 11:11:28 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=iO3qLjvc; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=sT7QGWrB3qJIKDj+qoEIMxAd6eLpLgPYO4PakEJ0TDs=; b=iO3qLjvcN90viV0xOvFgfayC81p2q4jxk3ohbG3qkPSndlBhgYD49nopVL8aHEhmSAKU 3QMuDz6Or8vKG4XwIKmie0wmkBmrBgAetKLZv74pqVBeXKNQX+rXOW5UaKlJVDZ0ms6f8R HzDo7nRtRygyuIEVQPjAnYyfCWOGmiec4owmtdOWK29rk6XXNqaTy0C0K8ZdaJXxD5G/77 pdAodKAxm9BAmBRj/bLrnCADVV+U1nmf2tukMms3nsxBd8Q8ngrbWShQ4wo5DyJ/0VowHS H3XgZyxlQkQVnfVus9MLXFyzP/qcinXEnQzqR/vfttSVBMvve/TLRWwyHyG1qhPg== Received: by filterdrecv-58bfc74dd6-gwqf5 with SMTP id filterdrecv-58bfc74dd6-gwqf5-1-65B0F05F-16 2024-01-24 11:11:27.411911108 +0000 UTC m=+73439.807855420 Received: from herokuapp.com (unknown) by geopod-ismtpd-28 (SG) with ESMTP id sl8p3VM6T62dkWxgUPqObg for ; Wed, 24 Jan 2024 11:11:27.363 +0000 (UTC) Date: Wed, 24 Jan 2024 11:11:27 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20205 X-Redmine-Issue-Author: byroot X-Redmine-Sender: duerst X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 92961 X-SG-EID: =?us-ascii?Q?sZFLhNnqjcW9Ht8ByfkgOQbWPVETXXFxLuf0UPwpQ=2FbXrx066LnwciY0taRhC1?= =?us-ascii?Q?++A6DTJJ4lt=2FzJkwBQUmmbJXhB+C4nQ033MjSGj?= =?us-ascii?Q?je1hQuZPUm5gEgmg1fmRp=2FiIxI75sfyinBiZgoF?= =?us-ascii?Q?6g6DoVC6PyelbSY4ZovqWD0s7egiZy4PMfsi69e?= =?us-ascii?Q?AA+keItiNl7SB9aSIFutwXKbmJRrW6GpvLBTow2?= =?us-ascii?Q?yODSkxNcmJgB6nsBB3tQX+7p66OHhIxZyALpfx5?= =?us-ascii?Q?3MNysviRcYtVxw=2FcGvkxQ=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== Message-ID-Hash: FDCHHC3T4WGD4ZGZZOEOAGX4W6M3WVIC X-Message-ID-Hash: FDCHHC3T4WGD4ZGZZOEOAGX4W6M3WVIC X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:116404] [Ruby master Feature#20205] Enable `frozen_string_literal` by default List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: duerst via ruby-core Cc: duerst Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c= ore.ml.ruby-lang.org/