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=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no 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 BC8791F463 for ; Sat, 28 Dec 2019 18:00:05 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D254C120ACA; Sun, 29 Dec 2019 02:59:47 +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 13B6312090C for ; Sun, 29 Dec 2019 02:59:45 +0900 (JST) Received: by filterdrecv-p3mdw1-56c97568b5-xjbx9 with SMTP id filterdrecv-p3mdw1-56c97568b5-xjbx9-19-5E07980F-39 2019-12-28 17:59:43.799618257 +0000 UTC m=+1012596.849520130 Received: from herokuapp.com (unknown [3.82.152.27]) by ismtpd0128p1mdw1.sendgrid.net (SG) with ESMTP id YrXCNtgyTBS3QPW8_otHbw for ; Sat, 28 Dec 2019 17:59:43.708 +0000 (UTC) Date: Sat, 28 Dec 2019 17:59:43 +0000 (UTC) From: sawadatsuyoshi@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72217 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16446 X-Redmine-Issue-Author: sawa X-Redmine-Sender: sawa 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?jFXA8Rt481sXUUIO9tYW1AJlMOZdNdlSw=2F5TfLCefGuCqckYxQ5Bwkff9fy6Ug?= =?us-ascii?Q?DctJOxGJV0hqymSXtlCXLawXTnD4zLFEj8ZLrup?= =?us-ascii?Q?BK65YHy6aOlIcnZj4RpcC31ICTL1wEXeiO4IGEj?= =?us-ascii?Q?1kCA1ZpcYQj8w9egb6aFaGXkudXmpAuBK4cyKlh?= =?us-ascii?Q?U7OCAAHbE69O4wYKs4plkQgnm0+uo9uyB288i7F?= =?us-ascii?Q?sReYUo5SpP1rK6pug=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96558 Subject: [ruby-core:96558] [Ruby master Feature#16446] Enumerable#take_*, Enumerable#drop_* counterparts with positive conditions 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 #16446 has been updated by sawa (Tsuyoshi Sawada). I understand some people thinking that adding all these methods is doing too much. I came up with an idea of using just one method: `Enumerable#cut`. It works like `String#partition` when it does not take an argument (but unfortunately, the method name `Enumerable#partition` is already used for a different purpose). ```ruby enum.cut(&:zero?) # # => [[1, 1], [0], [3, 3, 0, 5, 5]] ``` It would take optional keyword argument `:take` or `:drop`. ```ruby enum.cut(take: :left, &:zero?) # => [1, 1] enum.cut(drop: :left, &:zero?) # => [0, 3, 3, 0, 5, 5] enum.cut(drop: :right, &:zero?) # => [1, 1, 0] enum.cut(take: :right, &:zero?) # => [3, 3, 0, 5, 5] ``` ---------------------------------------- Feature #16446: Enumerable#take_*, Enumerable#drop_* counterparts with positive conditions https://bugs.ruby-lang.org/issues/16446#change-83491 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- #16441 led me to think about the issue more generally. When we want to split a series of iterations by the first element that satisfies (or dissatisfies) a condition, we have three factors to consider. (1) Whether we want the condition to work **negatively** or **positively** (2) Whether we want the first element to satisfy (or dissatisfy) the condition to be included in the **left** side or the **right** side of the split (3) Whether we want the **left** side or the **right** side in the returned output This leads us to eight possible combinations to consider. ```ruby enum = [1, 1, 0, 3, 3, 0, 5, 5].to_enum ``` | |(1)|(2)|(3)|method|example| |--|--|--|--|--|--| |1|negatively|left|left|`take_while`|`enum.foo1(&:nonzero?) # => [1, 1]`| |2|negatively|left|right|`drop_while`|`enum.foo2(&:nonzero?) # => [0, 3, 3, 0, 5, 5]`| |3|negatively|right|left||`enum.foo3(&:nonzero?) # => [1, 1, 0]`| |4|negatively|right|right||`enum.foo4(&:nonzero?) # => [3, 3, 0, 5, 5]`| |5|positively|left|left||`enum.foo5(&:zero?) # => [1, 1]`| |6|positively|left|right||`enum.foo6(&:zero?) # => [0, 3, 3, 0, 5, 5]`| |7|positively|right|left||`enum.foo7(&:zero?) # => [1, 1, 0]`| |8|positively|right|right||`enum.foo8(&:zero?) # => [3, 3, 0, 5, 5]`| Proposal #16441 asks for a method that corresponds to case 3 in the table above, but I think that would make the paradigm messy unless case 4 is also implemented. Either cases 3 and 4 should both be implemented, or both not. Actually, the current proposal is not about cases 3 and 4. I would leave that to #16641. In many use cases (including the first example in #16641), we want to detect the "marker element" by which we split the iterations. In the cases above, that can be the element `0`. In such use cases, it is more natural to describe the condition in positive terms (i.e., `zero?`) rather than negative terms (i.e., `nonzero?`). (And in other use cases, it might be the other way around.) So I would like to propose methods that correspond to cases 5, 6, 7, 8 above. Naming of the methods should be done systematically. As a candidate, I came up with the following: ||method| |--|--| |5|`take_before`| |6|`drop_before`| |7|`take_upto`| |8|`drop_upto`| -- https://bugs.ruby-lang.org/