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=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [IPv6:2a01:4f8:1c0c:6b10::1]) (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 1A9B21F44D for ; Tue, 19 Mar 2024 20:47:31 +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=lRR7SCiV; 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=Dlnlzv2Q; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 2802E834F4; Tue, 19 Mar 2024 20:47:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1710881244; bh=tLOo8gxobvBJyjR7Cv2NzMB9MyreK+cKp5+4Tekrp6w=; 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=lRR7SCiVhvl2FoEnhrwm5lU2PGiYTQU/M3hGGOJ8GEd20qbTyR6ljtBsfaw0cWcSb GSvKNhrDWv2k4QN8elZnYBuGmn/44gPOHqkp7kzKNslwVT0ROz8ooOwtich/2pNSvu pZt2RUZXQF0XVfmpaj86NXt8Tqb69cveJ0sBMmS0= Received: from s.csnrwnwx.outbound-mail.sendgrid.net (s.csnrwnwx.outbound-mail.sendgrid.net [198.37.146.154]) by nue.mailmanlists.eu (Postfix) with ESMTPS id E692C83170 for ; Tue, 19 Mar 2024 20:47:19 +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=Dlnlzv2Q; 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=n7pG9xM2uuHHi01/ZJbNY9R+Q2ocYbyZYn8jD5BQlto=; b=Dlnlzv2Qq9lIilMYN2gv1uaH0yHTREhU13B9D/tat/kHHiAMhXTWF2srPhiuo6y0LFnR XDHQHXKNAD9VMAPQw5n047x4xqwhonG7GIPnJfTls/QcoBFKj5+zox9lyO0QlGvnPDg6NQ kK14jQy+D3jsO6Hz9w6fl+TulqJcyoz9NyKHLr8yerxLasWpyq1QABKZh23DipDQuyTvWZ hGsyXngUwGblGOYXcimgcqU1zv5GSzbcWorl2hgRgwuEZGfId381jRy4iHG+uggivYOEZf 9BHIzi5xa3ZLlsSdqoMNvAdTMqIY6LlOnAETr8o/V9i++zxmM1/flvSb3VfdzY+Q== Received: by recvd-7555548f4d-b7nhw with SMTP id recvd-7555548f4d-b7nhw-1-65F9F9D6-2 2024-03-19 20:47:18.041606226 +0000 UTC m=+85581.795421749 Received: from herokuapp.com (unknown) by geopod-ismtpd-0 (SG) with ESMTP id FF0itDr4RHmpXO1XDYMVqg for ; Tue, 19 Mar 2024 20:47:17.993 +0000 (UTC) Date: Tue, 19 Mar 2024 20:47:18 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 16153 X-Redmine-Issue-Author: Dan0042 X-Redmine-Issue-Priority: Normal X-Redmine-Sender: Dan0042 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: 93804 X-SG-EID: =?us-ascii?Q?u001=2EHy4LB1bizMxDg=2Fk6r7dYDS9qUDe3jZN8DIPm4OS+F86l7XdLFEAVX=2F2lh?= =?us-ascii?Q?z0Jj=2Ft7J6DgKnq5Qaf6Ba4+egck=2FoKuUHMa9Cn6?= =?us-ascii?Q?7D+EQ8vUJVtfptVa=2FYqXSzpzNIbW1AmdvbifEM4?= =?us-ascii?Q?+m5SB4UZyApo4rEhgYvZBTmc4YPyiB=2FI=2F2v0Rke?= =?us-ascii?Q?AcAFJ=2F5Ac222sOgmUdmH1b3jKuMD6HHp5RrFcS1?= =?us-ascii?Q?tDbRK0ciB1H2wBEodIMJZSQ8HoENArkn=2FcBpGWG?= =?us-ascii?Q?obma1YW6kM8Mt=2FlBB+kpmz9XjA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: DIQGDYNABV2URGHJJU3NUOO5QPX3NJDU X-Message-ID-Hash: DIQGDYNABV2URGHJJU3NUOO5QPX3NJDU 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:117238] [Ruby master Feature#16153] eventually_frozen flag to gradually phase-in frozen strings List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "Dan0042 (Daniel DeLorme) via ruby-core" Cc: "Dan0042 (Daniel DeLorme)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #16153 has been updated by Dan0042 (Daniel DeLorme). This proposal is made redundant by #20205 chilled strings. Please close. ---------------------------------------- Feature #16153: eventually_frozen flag to gradually phase-in frozen strings https://bugs.ruby-lang.org/issues/16153#change-107325 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- Freezing strings can give us a nice performance boost, but freezing previously non-frozen strings is a backward-incompatible change which is hard to handle because the place where the string is mutated can be far from where it was frozen, and tests might not cover the cases of frozen input vs non-frozen input. I propose adding a flag which gives us a migration path for freezing strings. For purposes of discussion I will call this flag "eventually_frozen". It would act as a pseudo-frozen flag where mutating the object would result in a warning instead of an error. It would also change the return value of `Object#frozen?` so code like `obj = obj.dup if obj.frozen?` would work as expected to remove the warning. Note that eventually_frozen strings cannot be deduplicated, as they are in reality mutable. This way it would be possible for Symbol#to_s (and many others) to return an eventually_frozen string in 2.7 which gives apps and gems time to migrate, before finally becoming a frozen deduplicated string in 3.0. This might even open up a migration path for eventually using `frozen_string_literal:true` as default. For example if it was possible to add `frozen_string_literal:eventual` to all files in a project (or as a global switch), we could run that in production to discover where to fix things, and then change it to `frozen_string_literal:true` for a bug-free performance boost. ### Proposed changes * Object#freeze(immediately:true) * if `immediately` keyword is true, set frozen=true and eventually_frozen=false * if `immediately` keyword is false, set eventually_frozen=true UNLESS frozen flag is already true * String#+@ * if eventually_frozen is true, create a duplicate string with eventually_frozen=false * Object#frozen?(immediately:false) * return true if `immediately` keyword is false and eventually_frozen flag is true * rb_check_frozen * output warning if eventually_frozen flag is true ### Alternatively: the eventually_frozen flag is an internal detail only * OBJ_EVENTUAL_FREEZE * used instead of OBJ_FREEZE in `rb_sym_to_s` and others to set eventually_frozen=true * Object#freeze * set frozen=true and eventually_frozen=false * String#+@ * if eventually_frozen is true, create a duplicate string with eventually_frozen=false * Object#frozen? * return true (or maybe `:eventually`) if eventually_frozen flag is true * rb_check_frozen * output warning if eventually_frozen flag is true -- 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-core.ml.ruby-lang.org/