[#97319] [Ruby master Feature#16667] Allow parameters to Symbol#to_proc and Method#to_proc — jgomo3@...

Issue #16667 has been reported by jgomo3 (Jes俍 Gez).

10 messages 2020/03/01

[#97344] [Ruby master Feature#16670] Reverse order of `expression` in `pattern` for 1-line pattern matching while it's still experimental — ttilberg@...

Issue #16670 has been reported by ttilberg (Tim Tilberg).

9 messages 2020/03/03

[#97355] [Ruby master Misc#16671] BASERUBY version policy — ko1@...

Issue #16671 has been reported by ko1 (Koichi Sasada).

10 messages 2020/03/04

[#97359] [Ruby master Bug#16672] net/http leaves original content-length header intact after inflating response — justin.reid@...

Issue #16672 has been reported by jmreid (Justin Reid).

15 messages 2020/03/04

[#97390] [Ruby master Bug#16677] Negative integer powered (**) to a float number results in a complex — camille.drapier@...

Issue #16677 has been reported by CamilleDrapier (Camille Drapier).

25 messages 2020/03/07

[#97410] [Ruby master Bug#16680] [Breaking Change] Ruby 2.7 not support symlinks folder in $LOAD_PATH to work with autoload. — vil963@...

Issue #16680 has been reported by zw963 (Wei Zheng).

8 messages 2020/03/07

[#97416] [Ruby master Bug#16682] Ruby 2.7.0p0 crash on exit if there is an active RUBY_INTERNAL_EVENT_GC_EXIT tracepoint — jean.boussier@...

Issue #16682 has been reported by byroot (Jean Boussier).

16 messages 2020/03/09

[#97448] [Ruby master Feature#16688] Allow #to_path object as argument to system() — daniel@...42.com

Issue #16688 has been reported by Dan0042 (Daniel DeLorme).

12 messages 2020/03/11

[#97528] [Ruby master Misc#16693] DevelopersMeeting20200410Japan — mame@...

Issue #16693 has been reported by mame (Yusuke Endoh).

12 messages 2020/03/16

[#97536] [Ruby master Bug#16694] JIT vs hardened GCC with PCH — v.ondruch@...

Issue #16694 has been reported by vo.x (Vit Ondruch).

11 messages 2020/03/18

[#97538] [Ruby master Bug#16695] Stack consistency error when using the return value — s.wakeup31@...

Issue #16695 has been reported by s4ichi (takamasa saichi).

10 messages 2020/03/18

[#97554] [Ruby master Bug#16697] Hash.ruby2_keywords_hash?(value) should support any object — eregontp@...

Issue #16697 has been reported by Eregon (Benoit Daloze).

12 messages 2020/03/19

[#97609] [Ruby master Bug#16740] Deprecating and removing the broken Process.clock_getres — eregontp@...

Issue #16740 has been reported by Eregon (Benoit Daloze).

14 messages 2020/03/28

[#97621] [Ruby master Bug#16743] problem with multi threading [BUG] Segmentation fault — pauloo.jansen@...

Issue #16743 has been reported by paulorja (paulo jansen).

12 messages 2020/03/29

[#97629] [Ruby master Feature#16744] Flag to load current bundle without using bundle exec — headius@...

Issue #16744 has been reported by headius (Charles Nutter).

11 messages 2020/03/30

[ruby-core:97575] [Ruby master Bug#16701] Odd output when using _1 ("ordinary parameter is defined")

From: shevegen@...
Date: 2020-03-22 16:16:39 UTC
List: ruby-core #97575
Issue #16701 has been reported by shevegen (Robert A. Heiler).

----------------------------------------
Bug #16701: Odd output when using _1 ("ordinary parameter is defined")
https://bugs.ruby-lang.org/issues/16701

* Author: shevegen (Robert A. Heiler)
* Status: Open
* Priority: Normal
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
I have tried to reproduce this issue into a small script, so first the code, to ease
copy/pasting (don't mind the quality; I encountered this in a larger script, so I
just tried to narrow this down):

    @hash = {}
    @hash['abc'] = { :a=>1, :b=>2, :c=>3}
    @hash['def'] = { :d=>1, :e=>2, :f=>3}

    def foobar(i = hash)
      i.each {|first_argument, second_argument|
        pp _1
        pp second_argument
      }
    end

    foobar

If you run the above code, the following output is given by ruby:

**foobar.rb:7: ordinary parameter is defined**

I am a bit confused as to why this is given. So perhaps this is not a
bug after all, because it may be that named arguments can only be used if
there is no explicit name given to them, such as in the above script done
via **|first_argument**.

So this may not be a bug, but instead a wanted feature/specification. But if
I then understand this correctly then it **also** disallows the use of 
named parameters while being able to use pp _1 **if** we already gave a
name to the arguments. This then limits the functionality of pp _1 and I
am not entirely sure why this must be the case.

I like giving explicit names, but in the very middle of writing code, I'd
like to also be able to just quickly do e. g. "pp _1", often because
I may forget the name of hash keys and values or nested hashes. So
now I am a bit confused. Perhaps this is a bug, perhaps not. I have no
idea, so I report this here anyway.

If this is not a bug, though, then this artificially limits the usefulness
of _1 _2 since they are not allowed when we give an explicit name, which
I used to think was possible (I may have missed the full specification).

In such a situation I would then be forced to either use _1 _2
without an explicit name of the block parameters, or stick to
the block parameters instead. Since my primary use case was more to use
_1 _2 etc ... quickly, as means to be faster/shorter, that would mean
that I'd only use explicit names for block parameters and skip _1 completely,
which is also ok - I was just confused about the above behaviour, so I will
report this here anyway.



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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next