ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95067] [Ruby master Bug#16178] Numbered parameters: _1 should be the same as |x| and _0 should not exist
Date: Tue, 24 Sep 2019 21:45:30 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-81700.20190924214530.40ecb2061034f052@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16178.20190924132101@ruby-lang.org

Issue #16178 has been updated by Eregon (Benoit Daloze).


zverok (Victor Shepelev) wrote:
> Honestly, we use it pretty frequently in our codebase and find it appealing.
> It is the shortest and pretty clear (YMMV, of course) way of processing only first elemente of "tuple-alike" arrays, like zips of data or data with indexes.

How frequently compared to just `|x|`? I would guess < 5% on any non-trivial codebase.
But you are right, frequency of usage isn't so important.

I agree `|x,|` has its uses, and I think it's perfectly fine to use it when it's intentional.
The explicit trailing comma shows the intention to drop remaining args.

But `_1` shouldn't mean "drop everything but the first element if the first parameter is an Array, otherwise return the first parameter".
`_1` should mean "the first parameter" just like
`_2` means "the second parameter" and
`_3` means "the third parameter".

Would anyone contradict that? :p

> **Second**, we have "0 is whole, 1 is first match, etc." conditions in other places of Ruby—string matching:

Indeed, I didn't realize that symmetry.
I don't think it's good to have two different ways with subtle differences to refer to the 1st parameter though.
I believe `_1` must be simple to define and similar to `_2`.
It's all very confusing if `_0` is the first parameter and `_2` is the second parameter, isn't it?

> **Third**, I believe that in most of real, non-artificial situations, processing of sequence of heterogenous (some unpackable, some not) values with "shortcut blocks args" is a situation to either avoid, or being aware of your data nature.

What about libraries, e.g., taking an Enumerable from the application and using `enum.map { transform(_1) }`?
Do you think it's OK to have the library work if all elements are number but break horribly if all elements are arrays?
There are certainly a lot of methods that must behave identically (and not drop elements) no matter the class of the parameter passed to it.

Yes, `_0` can be used to avoid that, but then it's clear `_0` semantics should be preferred in all cases but those were dropping elements is intentional.
And then if it's intentional, we already have a great syntax showing it: `|x,|`.

So the syntax for the first, second, etc arguments should be consistent (i.e., `_1`, `_2`, `_3`), and by that `_1` must not decompose arrays and drop elements, but behave like `|x|`.
Quod Erat Demonstrandum.


> In your proposal, the last line should be, like

No, my proposal does not change the semantics of `{ [_1, _2.to_i] }`.
That is always the same as `{ |a,b| [a, b.to_i] }`.

----------------------------------------
Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not exist
https://bugs.ruby-lang.org/issues/16178#change-81700

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
* ruby -v: ruby 2.7.0dev (2019-09-24T12:57:54Z master 0e84eecc17) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Currently on trunk:
```ruby
array = ["string", 42, [1, 2]]

array.map { |x| x * 2 }
# => ["stringstring", 84, [1, 2, 1, 2]]

array.map { _1 * 2 }
# => ["stringstring", 84, 2]
```

Oops, this trivial code just lost data and completely ignored the element class!
This is clearly contrary to intuition and is very dangerous.

Using `_0` instead has the correct behavior but it's clear we use 1-based indexing for numbered parameters,
and it doesn't solve that `_1` has dangerous behavior.

Basically the current behavior is that `_0` is the same as `|x|` and `_1` is the same as `|x,|`.
`|x,|` is almost never used in Ruby, and for good reasons, it just throws away data/information/the class of the object.
Such a dangerous operation should only be done when it's explicit, and the trailing comma in `|x,|` shows that, but `_1` does not.

So let's make `_1` be `|x|` and remove `_0`.

I am going to be harsh, but this discussion has gone too long without any serious written argument for the current behavior:
I believe it's irrational and irresponsible to have `_1` be `|x,|`, it's just going to lead to nasty bugs.

Try to convince me otherwise.
If not, in one week I want to apply this change.

From the discussion in https://bugs.ruby-lang.org/issues/15723#note-127
and in https://bugs.ruby-lang.org/issues/15708

Some reactions to this behavior in https://twitter.com/eregontp/status/1115318993299083265



-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2019-09-24 21:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16178.20190924132101@ruby-lang.org>
2019-09-24 13:21 ` [ruby-core:95056] [Ruby master Bug#16178] Numbered parameters: _1 should be the same as |x| and _0 should not exist eregontp
2019-09-24 13:23 ` [ruby-core:95057] " eregontp
2019-09-24 13:29 ` [ruby-core:95058] " nobu
2019-09-24 13:37 ` [ruby-core:95059] " eregontp
2019-09-24 13:53 ` [ruby-core:95060] " zverok.offline
2019-09-24 16:04 ` [ruby-core:95062] " shevegen
2019-09-24 21:38 ` [ruby-core:95066] " daniel
2019-09-24 21:45 ` eregontp [this message]
2019-09-24 22:14 ` [ruby-core:95069] " eregontp
2019-09-24 22:19 ` [ruby-core:95070] " eregontp
2019-09-24 22:39 ` [ruby-core:95071] " eregontp
2019-09-25  3:27 ` [ruby-core:95074] " matz
2019-09-25 10:15 ` [ruby-core:95079] " daniel
2019-09-25 10:44 ` [ruby-core:95080] " sawadatsuyoshi
2019-09-25 11:16 ` [ruby-core:95082] " fg
2019-09-25 11:54 ` [ruby-core:95085] " ko1
2019-09-25 12:39 ` [ruby-core:95086] " daniel
2019-09-25 16:12 ` [ruby-core:95087] " eregontp
2019-09-25 16:13 ` [ruby-core:95088] " eregontp
2019-09-26 17:30 ` [ruby-core:95116] " XrXr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-81700.20190924214530.40ecb2061034f052@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).