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

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

[merch-redmine]

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/

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

[matz (Yukihiro Matsumoto)]

Issue #15357 has been updated by matz (Yukihiro Matsumoto).


Hmm, I accept `lambda:` keyword argument (default `false`). There might be a better candidate than `lambda` but it's acceptable at least.

Matz.


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

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

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

[Eregon (Benoit Daloze)]

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


A lambda: kwarg when it's meant to be used for non-lambda Procs seems confusing.
How about `parameters(from: :source)`, and the default would be `parameters(from: :behavior)`?
Could also be `parameters(from_source: true/false)` or so.

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

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