From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95069] [Ruby master Bug#16178] Numbered parameters: _1 should be the same as |x| and _0 should not exist
Date: Tue, 24 Sep 2019 22:14:34 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-81702.20190924221433.222d64f1012cd355@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16178.20190924132101@ruby-lang.org
Issue #16178 has been updated by Eregon (Benoit Daloze).
Dan0042 (Daniel DeLorme) wrote:
> `proc{ |x,| }.arity` == 1, so `_1` is consistent with that.
Which sounds like another bug to me, because that block happily accepts more arguments, and should be identical to `|x,*|`, which `proc {|x,*|}.arity # => -2`.
What is your point?
My point about arity was that if you add an argument, arity changes, and behavior changes too.
Everyone understands adding an extra argument to a block (or lambda) might change semantics (e.g., `[1,[2,3]].map(&-> { _1; _2 })` is ArgumentError), isn't it?
That's already the case today with named parameters.
How do you argue that `_2` "takes the second parameter" but `_1` "extracts the first element of the first parameter"?
How is that consistent?
> In order to get the tuples' first value you would need to do `array_of_arrays.map{_2;_1}` because otherwise `_1` would mean the entire tuple.
You would need to do `array_of_arrays.map { |x,| x }`. The tiny extra verbosity is warranted for dropping elements.
Try adding 1 to each element of a 2 dimensional array (a matrix).
`_0` must be used currently, but really taking the element as it is (`|x|`) are the only correct semantics in general if you do not know the specific element types.
Why would the correct semantics in general need a different syntax (`_0` and not `_1`)?
BTW, about typing, how would you type `enum.map { _1 }` with enum an `Enumerable[T]`?
Isn't it impossible, because the behavior is inconsistent at runtime?
> This argument is really weird. Is it really so unsufferable to use `_0` instead of `_1`?
Yes, it's inconsistent and I'm pretty sure people would use `_1` like `|x|`, without realizing it's just broken when it's passed an Array.
Do we want frequent bugs based on this instead of just having to use `|x,|` when wanting to drop elements?
----------------------------------------
Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not exist
https://bugs.ruby-lang.org/issues/16178#change-81702
* 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/
next prev parent reply other threads:[~2019-09-24 22:15 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 ` [ruby-core:95067] " eregontp
2019-09-24 22:14 ` eregontp [this message]
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-81702.20190924221433.222d64f1012cd355@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).