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.9 required=3.0 tests=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 493131F4B4 for ; Tue, 30 Mar 2021 21:13:09 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id B0933120E36; Wed, 31 Mar 2021 06:12:06 +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 C7936120E34 for ; Wed, 31 Mar 2021 06:12:04 +0900 (JST) Received: by filterdrecv-p3iad2-7d7c446bd4-mfhjf with SMTP id filterdrecv-p3iad2-7d7c446bd4-mfhjf-21-60639456-5C 2021-03-30 21:12:54.931317804 +0000 UTC m=+614389.836584503 Received: from herokuapp.com (unknown) by ismtpd0165p1iad2.sendgrid.net (SG) with ESMTP id mjeAj11eQQ29d6yuN7U8Hg for ; Tue, 30 Mar 2021 21:12:54.913 +0000 (UTC) Date: Tue, 30 Mar 2021 21:12:54 +0000 (UTC) From: dan@danamis.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 79148 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 16295 X-Redmine-Issue-Author: byroot X-Redmine-Sender: danh337 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?W222LJUvwIJXD0fuSPUfn3L88E5kwATu3GdlfyyAnYvV9Fjoht0ihlKxLVOdHN?= =?us-ascii?Q?oLUYChf9oVxhMeySG+LBqgrQhdOIwsRxF+BKUxX?= =?us-ascii?Q?sXWV6HgDmHfdfI=2FUELtlgQgTpT7MESqGCw8jic9?= =?us-ascii?Q?7z6nfBNr1Zif8IbqkHdnJvaKJc9jrrp2lTJs9G1?= =?us-ascii?Q?03Fe8ddr8PzmOPVNcP4aETv48PyvDS8U2EBzsvI?= =?us-ascii?Q?X31UlxB4b5573cn5U=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 103113 Subject: [ruby-core:103113] [Ruby master Feature#16295] Chainable aliases for String#-@ and 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 #16295 has been updated by danh337 (Dan Higgins). The `-@` and `+@` calls do work fine for chaining. But `.-@` has a nice equivalent, `.freeze`. Is it possible to give `.+@` a nice equivalent, like `.thaw`? This feels more Rubyistic. Are newer Ruby MRIs going to have core methods return frozen strings more often? If so, then chaining these freeze and "thaw" methods will be more common. This already has made some of my production code ugly, when using `tap`. I have to say: `(+some_object.send(a_method)).tap { |value| value << "blah" }` or `some_object.send(a_method).+@.tap { |value| value << "blah" }` Neither of these looks like good Ruby. I'd rather say `some_object.send(a_method).thaw.tap { |value| value << "blah" }`. ---------------------------------------- Feature #16295: Chainable aliases for String#-@ and String#+@ https://bugs.ruby-lang.org/issues/16295#change-91179 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Original discussion https://bugs.ruby-lang.org/issues/16150?next_issue_id=16147&prev_issue_id=16153#note-40 In #16150, @headius raised the following concern about `String#-@` and `String#+@`: headius (Charles Nutter) wrote: > > Not exactly, -@ and +@ makes this much simpler > > I do like the unary operators, but they also have some precedence oddities: > > ``` > >> -"foo".size > => -3 > >> (-"foo").size > => 3 > ``` > > And it doesn't work at all if you're chaining method calls: > > ``` > >> +ary.to_s.frozen? > NoMethodError: undefined method `+@' for false:FalseClass > from (irb):8 > from /usr/bin/irb:11:in `
' > ``` > > But you are right, instead of the explicit `dup` with possible freeze you could use `-` or `+` on the result of `to_s`. However it's still not safe to modify it since it would modify the original string too. After working for quite a while with those, I have to say I agree. They very often force to use parentheses, which is annoying, and an indication that regular methods would be preferable to unary operators. In response @matz proposed to alias them as `String#+` and `String#-` without arguments: > How about making String#+ and #- without argument behave like #+@ and #-@ respectively, so that we can write: > > ``` > "foo".-.size > ary.to_s.+.frozen? > ``` My personal opinion is that descriptive method names would be preferable to `+/-`: > IMHO `.-` and `.+` is not very elegant. Proper method names explaining the intent would be preferable. > > - `-@` could be `dedup`, or `deduplicate`. > - `+@` could be `mutable` or `mut`. -- https://bugs.ruby-lang.org/