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 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 030061F44D for ; Thu, 18 Apr 2024 06:22:44 +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=Lf7ReYiG; 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=YdC1Mjlo; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 4F59B843AA; Thu, 18 Apr 2024 06:22:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1713421356; bh=00OCHA4cdAy6+c9z6n6/zoDugMSuk8lMeUCfwKY4wgE=; 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=Lf7ReYiGX0T9EVSGw0VmRrDCYmF1D1AnVJd4WPNtw84QV/+QR3t0qT9koGmdUelvW zOv0cr8GJJHpPHcB8SiqVaO43C1DMM6YiiF8R7xcxQ6lTdYYBvSPbYGsBSqNEpeaCP IdpEhTmP057PCfyEghCYeX4AXiaElaQLTQ5kQpTs= Received: from s.wrqvtzvf.outbound-mail.sendgrid.net (s.wrqvtzvf.outbound-mail.sendgrid.net [149.72.126.143]) by nue.mailmanlists.eu (Postfix) with ESMTPS id AD45F84398 for ; Thu, 18 Apr 2024 06:22:32 +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=YdC1Mjlo; 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=vLrjlmj/ov/D1gxzETnWn092cGJn3Zg0dI9nUgBXfMI=; b=YdC1Mjlou4LX657pLH7yyNr7jZS9FtTQLFbdgF7vI7XiVt7e8tHu71H6VgymrwWbNvRa 2+lypJ1Mh+aXCwj3SkvQTywYDOc0zAcxtJ22VHCFsnV/jh6M4JQvW98S3fChFrsSyPLJ+O G5ZRli8hINAgCSmhG0tp8Qhbtg8KGfPfh0R+gZw2cScLPIb6WOdhaJF06ph7Bk6bEfwvY3 x9NV2flzCA0bK4kYvSy1h2oo6IUBKb+DsTu30deNG8RC9l4uH/XZas2/kwd2C070rfy/kg lploDorhZXiWjudDjMKHVuLjaxR9qo18iu7JpQsRpv4d3QYlif2qYlGalU15rKBg== Received: by recvd-6b888cd74b-sm565 with SMTP id recvd-6b888cd74b-sm565-1-6620BC27-B 2024-04-18 06:22:31.534946901 +0000 UTC m=+462084.481020192 Received: from herokuapp.com (unknown) by geopod-ismtpd-23 (SG) with ESMTP id xj8XLaJ_ShCUReiEb5F3KA for ; Thu, 18 Apr 2024 06:22:31.500 +0000 (UTC) Date: Thu, 18 Apr 2024 06:22:30 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Misc X-Redmine-Issue-Id: 20434 X-Redmine-Issue-Author: kddnewton X-Redmine-Issue-Priority: Normal 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: 94187 X-SG-EID: =?us-ascii?Q?u001=2EVSImDo3=2FLGFC=2FEuu2m1f=2FEiaVrc7lz1mqWB5smyUP7UUn=2FCYlcvDtGAwP?= =?us-ascii?Q?3SLVrmV77rl1BxnAhyKPeUuM4dvN5K1BuI5Y5mM?= =?us-ascii?Q?T4R9DV7BaUtYwOhxUqPC2jJ6eSWvEjkMfCUJ633?= =?us-ascii?Q?6yUpjtYLpkFdAREyTN5+pwTWGyuHgs=2F4tF6FxYO?= =?us-ascii?Q?EQOvC2tlRj5I6ApXM2xSZJwNF8uEWMz2V9MJqGl?= =?us-ascii?Q?ApkwcLuu=2FCvyV9Tvgej8NSkQ5+EjFWvrmTqVlPx?= =?us-ascii?Q?qE7h?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: H4I7AVICA5UA5KDRB2CCN2NXXXTXBEIJ X-Message-ID-Hash: H4I7AVICA5UA5KDRB2CCN2NXXXTXBEIJ 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:117591] [Ruby master Misc#20434] Deprecate encoding-releated regular expression modifiers 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 #20434 has been updated by duerst (Martin D=FCrst). I guess there might still be some use for the encoding-related modifiers in= single-line scripts and the like. But I don't have an actual use case; I h= ope whoever has such an use case comes forward. The replacement code (`::Regexp.new(::String.new("\x81\x40", encoding: "Win= dows-31J"))`) is quite lengthy. This makes it clear that while each regular= expression has an encodings in the same way as each String has an encoding= , regular expressions don't really allow to manipulate the encoding. String= s have #force_encoding and #encode, so maybe adding one or both methods to = Regexp would help. The example could then be written as `/\x81\x40/.force_e= ncoding("Windows-31J")` or /\3000/.encode("Windows-31J"). ---------------------------------------- Misc #20434: Deprecate encoding-releated regular expression modifiers https://bugs.ruby-lang.org/issues/20434#change-107992 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- This is a follow-up to @duerst's comment here: https://bugs.ruby-lang.org/i= ssues/20406#note-6. As noted in the other issue, there are many encodings that factor in to how= a regular expression operates. This includes: * The encoding of the file * The encoding of the string parts within the regular expression * The regular expression encoding modifiers * The encoding of the string being matched At the time the modifiers were introduced, I believe the modifiers may have= been the only (??) encoding that factored in here. At this point, however,= they can lead to quite a bit of confusion, as noted in the other ticket. I would like to propose to deprecate the regular expression encoding modifi= ers. Instead, we could suggest in a warning to instead create a regular exp= ression with an encoded string. For example, when we find: ```ruby /\x81\x40/s ``` we would instead suggest: ```ruby ::Regexp.new(::String.new("\x81\x40", encoding: "Windows-31J")) ``` or equivalent. As a migration path, we could do the following: 1. Emit a warning to change to the suggested expression 2. Change the compiler to compile to the suggested expression when those fl= ags are found 3. Remove support for the flags Step 2 may be unnecessary depending on how long of a timeline we would like= to provide. To be clear, I'm not advocating for any particular timeline, a= nd would be fine with this being multiple years/versions to give plenty of = time for people to migrate. But I do think this would be a good change to e= liminate confusion about the interaction between the four different encodin= gs at play. --=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/