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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 081401F5CB for ; Sat, 5 Oct 2024 19:47:13 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=aQJZa6O8; 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=q8HoHP3d; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1728157631; bh=Uthkac6vGOfSN7mA+Z9wUjuJZXUCMBq3/CqNpnjuim0=; 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=aQJZa6O8Jq11fX5wSvjxfCJxVerDbugkb+y6Z3MopPAvV5zR199lLxT/NuIFxzo5E xG8lllF8Eyx3xgmME19Gr5gs+WxEx4/Kf/kLU54RUTso1BCFF0iRWGeLoWjPpdV6yh rTPhMtgemqdqUQDzGlNMMdEOABUjfra02hENDrRg= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 27F4243F9E for ; Sat, 5 Oct 2024 19:47:11 +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=q8HoHP3d; dkim-atps=neutral Received: from s.wrqvtbkv.outbound-mail.sendgrid.net (s.wrqvtbkv.outbound-mail.sendgrid.net [149.72.123.24]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 66FAA43CFB for ; Sat, 5 Oct 2024 19:46:59 +0000 (UTC) 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=8/Sqywr0b0YGyQ0nDy16Pj0vE8zskXukFqBhafJspcU=; b=q8HoHP3dkRFQDKQOdxL9uakC52LsjcEzk9pBl+T6Eek2oBG3ugYzHJJcjA7FMMk1tQcg SLVXuio96KqN7L7pzrT0qI+ihsZ1sYTPuqgDwDO9g4y9KGurD8Iu2QAYRVBJZ/aj7yxpl8 2xnpKaXNPkDSnq8F8VrTWFTBKim2997lTsN8QlcMwIVRHVCy1hBB2SqSGM3ffHsZf/8l31 x2LXFRH0QEAArgCE7z+Wjk5ZwNmH7hPUDW6Hsqai0tXXC3K4Oew6ef6fyJmujtSRlEX3vE QlUxN0NEZx5pAPnPUToq3FqirlUHof2AGvHXqU4reump1lELvzvQ7kliG89tQJQA== Received: by recvd-d66cff667-9t457 with SMTP id recvd-d66cff667-9t457-1-670197B1-15 2024-10-05 19:46:57.935470125 +0000 UTC m=+1993825.563711867 Received: from herokuapp.com (unknown) by geopod-ismtpd-2 (SG) with ESMTP id ShoKcX4rR8u30Q4puf1YlQ for ; Sat, 05 Oct 2024 19:46:57.835 +0000 (UTC) Date: Sat, 05 Oct 2024 19:46:57 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20770 X-Redmine-Issue-Author: AlexandreMagro X-Redmine-Issue-Priority: Normal X-Redmine-Sender: nevans 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: 96102 X-SG-EID: =?us-ascii?Q?u001=2E=2FrMauBqaU1JMnnbwOvuwb8srbhagHePXgDmUDHf+N56sJzPMY8mRnQzst?= =?us-ascii?Q?N+jmwaaOiY3ZRRrX06nWRur+h4rV1kR40lw7=2Fgb?= =?us-ascii?Q?CY9OeSB04QdHw=2F6SqeuwF9JL9FMBdEqLtDcaZU7?= =?us-ascii?Q?qD6JNgqFB6ipX3CsGtiUmTTPKw4R4hBnLBR=2F+2=2F?= =?us-ascii?Q?SyA9QqWbCWU58tajj0hjWrdsS+kF8ebPM70y1Se?= =?us-ascii?Q?YIjjnKjlohW6mFjnmNxipmHZBnsHxUjBn4soGpc?= =?us-ascii?Q?F6qJPop3mlypYpc0AEtE=2FZyHuw=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: DUJ7EVSN6OB3J5YCBT5WVC3V25GYQL2N X-Message-ID-Hash: DUJ7EVSN6OB3J5YCBT5WVC3V25GYQL2N 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.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:119466] [Ruby master Feature#20770] A *new* pipe operator proposal List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "nevans (Nicholas Evans) via ruby-core" Cc: "nevans (Nicholas Evans)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20770 has been updated by nevans (Nicholas Evans). I think there are good reasons to want a `|>` operator in addition to (or instead of) `.{}`, but `foo.{ bar it }` is intriguing syntactic sugar. I think I like it. I just noticed that [it was rejected by Matz](https://bugs.ruby-lang.org/issues/12760#note-17) when `#yield_self` was introduced. But perhaps (when the syntax moratorium has ended) time will have changed his mind? It does seem to have a natural connection to `foo.()`. _But_, I would strongly prefer for it to be an alias for `#yield_self`; ***not*** for `#then`. Maybe that's a subtle distinction. Many rubyists seem to treat `#then` as a pure alias for `#yield_self`. But they are _not_ perfect synonyms. When `#then` was first proposed, Matz specifically mentioned [that they have different semantics](https://bugs.ruby-lang.org/issues/14594#note-17): > It is introduced that a normal object can behave like promises. > So the name conflict is intentional. > If you really wanted a non-unwrapping method for promises, use `yield_self`. In other words, we should not assume that every object implements `#then` the exact same way. I have a lot of async code that predates `Object#then`. From a purely linguistic viewpoint, when we're dealing with a object that represents a completable process, the English word "then" strongly implies that the block will only run _after_ the process has completed. So I treat `#yield_self` and `#then` the same way that I treat `equal?`, `eql?`, `==`, and `#===`. The fact that all of these behave more-or-less identically on Object is not determinative: classes _should_ override `#eql?`, `#==`, and `#===` to properly represent the different forms of equality. Likewise, `#then` _should_ be overridden for any object that represents a completable process. On the other hand, just like `#equal?`, `#yield_self` should _never_ be overridden, and it should only occasionally even be used. I will use `#equal?` or `#yield_self` when the _semantics_ fit, even if that particular object doesn't override `#==` and `#then`. E.g: ```ruby # runs immediately: so "then" is not appropriate Thread.new do do_stuff end .yield_self { register_task_from_thread it } # waits for `Thread#value`: so "then" is appropriate Thread.new do do_stuff end .then { handle_result it.value } async { get_result } # returns a promise .then {|result| use result } # probably _also_ returns a promise .value # unwrap the promise ``` I do think there is room for a `|>` operator that is yet another version of this, with slightly different semantics from both `#yield_self` and `#then`. But (concerning this proposal) I share @zverok's concern about creating "an invisible block like nowhere else". We should be _very_ careful about adding unique syntax for a single operator. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110084 * Author: AlexandreMagro (Alexandre Magro) * Status: Open ---------------------------------------- Hello, This is my first contribution here. I have seen previous discussions around introducing a pipe operator, but it seems the community didn't reach a consensus. I would like to revisit this idea with a simpler approach, more of a syntactic sugar that aligns with how other languages implement the pipe operator, but without making significant changes to Ruby's syntax. Currently, we often write code like this: ```ruby value = half(square(add(value, 3))) ``` We can achieve the same result using the `then` method: ```ruby value = value.then { add(_1, 3) }.then { square(_1) }.then { half(_1) } ``` While `then` helps with readability, we can simplify it further using the proposed pipe operator: ```ruby value = add(value, 3) |> square(_1) |> half(_1) ``` Moreover, with the upcoming `it` feature in Ruby 3.4 (#18980), the code could look even cleaner: ```ruby value = add(value, 3) |> square(it) |> half(it) ``` This proposal uses the anonymous block argument `(_1)`, and with `it`, it simplifies the code without introducing complex syntax changes. It would allow us to achieve the same results as in other languages that support pipe operators, but in a way that feels natural to Ruby, using existing constructs like `then` underneath. I believe this operator would enhance code readability and maintainability, especially in cases where multiple operations are chained together. Thank you for considering this proposal! -- 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/lists/ruby-core.ml.ruby-lang.org/