From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id BB9C11F454 for ; Wed, 6 Nov 2019 01:12:03 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id F2CD2120BA0; Wed, 6 Nov 2019 10:11:52 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 47572120B9F for ; Wed, 6 Nov 2019 10:11:51 +0900 (JST) Received: by filter0081p3iad2.sendgrid.net with SMTP id filter0081p3iad2-6342-5DC21DD9-6 2019-11-06 01:11:53.073392546 +0000 UTC m=+26447.114176490 Received: from herokuapp.com (unknown [54.204.69.61]) by ismtpd0008p1iad2.sendgrid.net (SG) with ESMTP id x9w41KUDSvOWl8HUCVDlbA for ; Wed, 06 Nov 2019 01:11:52.982 +0000 (UTC) Date: Wed, 06 Nov 2019 01:11:53 +0000 (UTC) From: mame@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71309 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16294 X-Redmine-Issue-Author: Eregon X-Redmine-Sender: mame 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-SG-EID: =?us-ascii?Q?EJh2gqwnyqXtd++xo=2FinyA1V0bXouTB4FkWnzNiKb4=2FNS3domFwIijUKtB6AQU?= =?us-ascii?Q?0x=2FvV7NnYNDqNQ4zQ2SM6oWkT2QMHNSgPy70lmY?= =?us-ascii?Q?mnSEJfT=2FM1bsmIhLoUGmG5VBaeAydXCKy9TLYZC?= =?us-ascii?Q?d+qmrqYV50GRrkmcLlNdiDy2uZU78hYKyaWRG+d?= =?us-ascii?Q?VesSk2NCNk=2FujcZz=2FGloR0AiAT=2FtMtDRVyg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95717 Subject: [ruby-core:95717] [Ruby master Feature#16294] Make MatchData frozen and forbid MatchData.allocate X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16294 has been updated by mame (Yusuke Endoh). I'm not against the proposal itself, but is it okay to introduce an incompatibility at this time? cc: @naruse ---------------------------------------- Feature #16294: Make MatchData frozen and forbid MatchData.allocate https://bugs.ruby-lang.org/issues/16294#change-82504 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Assignee: * Target version: ---------------------------------------- Currently, `MatchData.allocate` is allowed, but almost every MatchData method called on it `raise TypeError, 'uninitialized Match'`. I think MatchData should be frozen, none of its internal fields are mutable and I don't see any use case for storing instance variables on it. Once frozen, we can implement MatchData#dup and #clone as just `return self`, and we don't need to check for the uninitialized case. And Marshal can have special treatment to create an initialized MatchData directly. My main motivation is looking at the code in TruffleRuby required to implement `MatchData.allocate` and check if it's initialized in so many places: https://github.com/oracle/truffleruby/pull/1792/files Thoughts? Anyone against? cc @alanwu -- https://bugs.ruby-lang.org/