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-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY 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 3FEB31F66F for ; Sat, 21 Nov 2020 07:31:55 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 6D480120B03; Sat, 21 Nov 2020 16:31:07 +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 3304D120A10 for ; Sat, 21 Nov 2020 16:31:03 +0900 (JST) Received: by filterdrecv-p3las1-6665f6549b-84zxv with SMTP id filterdrecv-p3las1-6665f6549b-84zxv-19-5FB8C25F-2A 2020-11-21 07:31:43.601414593 +0000 UTC m=+385247.453795942 Received: from herokuapp.com (unknown) by ismtpd0068p1mdw1.sendgrid.net (SG) with ESMTP id 5DKcPWzNTQ6YrlCgw2fr4A for ; Sat, 21 Nov 2020 07:31:43.444 +0000 (UTC) Date: Sat, 21 Nov 2020 07:31:43 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76874 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 10845 X-Redmine-Issue-Author: sawa X-Redmine-Issue-Assignee: matz X-Redmine-Sender: jeremyevans0 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?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BIp8ft8qUQv+fIlfw1Cx4hOYFcuiVK+9V9izhEd?= =?us-ascii?Q?NU0grApU2POyZUSJ5o0NjPwILK7zAUZeYDKHelc?= =?us-ascii?Q?NHSAfoebissBi6I62aSy856gLac+lTQP+MYQl+a?= =?us-ascii?Q?+HScDNxXlgnYYrhqcmw=2Fn+Bg3C9oC9yt88lwywU?= =?us-ascii?Q?ae17PVaAakCXl2v9Q=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 101000 Subject: [ruby-core:101000] [Ruby master Bug#10845] Subclassing String 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 #10845 has been updated by jeremyevans0 (Jeremy Evans). naruse (Yui NARUSE) wrote in #note-16: > In 2.7 we break large compatibilities, and this tickets breaks Rails again. > "Rails master already fixes it" doesn't care the problem; we breaks compatibility. In this case, Ruby's behavior resulted in objects that were not internally consistent. Rails has a fair amount of code just to work around the inconsistency , which they will be able to drop once 3.0 is the minimum version (Rails 7?). See https://github.com/rails/rails/blob/1165401ee962aef0aaf81080e3e7dcab522efa40/activesupport/lib/active_support/core_ext/string/output_safety.rb#L248-L253 I appreciate the importance of backwards compatibility. Almost all of my libraries run on Ruby 1.9 - Ruby 3.0. However, I don't think we should skip fixing problems in core Ruby just because it breaks a small part of Rails, especially if fixing the issue in Rails is simple. We should always weigh the costs and benefits when deciding whether compatibility should be broken. That being said, I respect your opinion, and if this experiment causes too many issues, we can revert. ---------------------------------------- Bug #10845: Subclassing String https://bugs.ruby-lang.org/issues/10845#change-88668 * Author: sawa (Tsuyoshi Sawada) * Status: Closed * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * ruby -v: 2.2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- If I make a subclass of `String`, the method `*` returns an instance of that class. ~~~ruby class MyString < String end MyString.new("foo").*(2).class #=> MyString ~~~ This is different from other similar operations like `+` and `%`, which return a `String` instance. ~~~ruby MyString.new("foo").+("bar").class #=> String MyString.new("%{foo}").%(foo: "bar").class #=> String ~~~ I don't see clear reason why `*` is to be different from `+` and `%`, and thought that perhaps either the behaviour with `*` is a bug, or the behaviour with `+` and `%` is a bug. Or, is a reason why they are different? -- https://bugs.ruby-lang.org/