[#99002] [Ruby master Feature#17004] Provide a way for methods to omit their return value — shyouhei@...

Issue #17004 has been reported by shyouhei (Shyouhei Urabe).

21 messages 2020/07/01

[#99044] [Ruby master Bug#17007] SystemStackError when using super inside Module included and lexically inside refinement — eregontp@...

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

7 messages 2020/07/03

[#99078] [Ruby master Feature#17016] Enumerable#scan_left — finch.parker@...

Issue #17016 has been reported by parker (Parker Finch).

42 messages 2020/07/07

[#99079] [Ruby master Bug#17017] Range#max & Range#minmax incorrectly use Float end as max — bosticko@...

Issue #17017 has been reported by sambostock (Sam Bostock).

25 messages 2020/07/07

[#99097] [Ruby master Bug#17021] "arm64" and "arm" are mixed in RbConfig on Apple silicon — watson1978@...

Issue #17021 has been reported by watson1978 (Shizuo Fujita).

9 messages 2020/07/09

[#99115] [Ruby master Bug#17023] How to prevent String memory to be relocated in ruby-ffi — larskanis@...

Issue #17023 has been reported by larskanis (Lars Kanis).

22 messages 2020/07/10

[#99156] [Ruby master Bug#17030] Enumerable#grep{_v} should be optimized for Regexp — marcandre-ruby-core@...

Issue #17030 has been reported by marcandre (Marc-Andre Lafortune).

25 messages 2020/07/13

[#99257] [Ruby master Misc#17041] DevelopersMeeting20200826Japan — mame@...

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

18 messages 2020/07/22

[#99308] [Ruby master Feature#17047] Support parameters for MAIL FROM and RCPT TO — bugs.ruby-lang.org@...

Issue #17047 has been reported by c960657 (Christian Schmidt).

11 messages 2020/07/23

[#99311] [Ruby master Bug#17048] Calling initialize_copy on live modules leads to crashes — XrXr@...

Issue #17048 has been reported by alanwu (Alan Wu).

17 messages 2020/07/24

[#99351] [Ruby master Bug#17052] Ruby with LTO enabled on {aarch64, ppc64le} architectures. — v.ondruch@...

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

35 messages 2020/07/27

[#99375] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings — merch-redmine@...

Issue #17055 has been reported by jeremyevans0 (Jeremy Evans).

29 messages 2020/07/28

[#99391] [Ruby master Feature#17059] epoll as IO.select — dsh0416@...

Issue #17059 has been reported by dsh0416 (Delton Ding).

18 messages 2020/07/29

[#99418] [Ruby master Feature#17097] `map_min`, `map_max` — sawadatsuyoshi@...

Issue #17097 has been reported by sawa (Tsuyoshi Sawada).

11 messages 2020/07/31

[ruby-core:99373] [Ruby master Feature#15357] Proc#parameters returns incomplete type information

From: merch-redmine@...
Date: 2020-07-28 20:19:40 UTC
List: ruby-core #99373
Issue #15357 has been updated by jeremyevans0 (Jeremy Evans).


@matz considered this during the March 2020 developers meeting, but has not yet made a decision on it.

----------------------------------------
Feature #15357: Proc#parameters returns incomplete type information
https://bugs.ruby-lang.org/issues/15357#change-86779

* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
----------------------------------------
The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800).
This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods.

Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently:

```ruby
pr = proc{|a,b=2| [a,b] }
pr.parameters  # => [[:opt, :a], [:opt, :b]]
pr.call(:a)    # => [:a, 2]  # :a is interpret as the first parameter

pr = proc{|a=1,b| [a,b] }
pr.parameters  # => [[:opt, :a], [:opt, :b]]
pr.call(:a)    # => [1, :a]  # :a is interpret as the second parameter
```

That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. In Eventbox a workaround is used: The proc is passed to `define_method` and the [method parameters are retrieved instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17). That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built.

The application of argument assignment tricks is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well.

My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` shows positional arguments without default value as type `:req` as well.


---Files--------------------------------
proc-parameters-req-15357.patch (5.15 KB)


-- 
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