[#98621] Re: Function getlogin_r()'s protoype] — Bertram Scharpf <lists@...>
FYI,
3 messages
2020/06/02
[#98947] [Ruby master Feature#16986] Anonymous Struct literal — ko1@...
Issue #16986 has been reported by ko1 (Koichi Sasada).
66 messages
2020/06/26
[#98962] [Ruby master Bug#16988] Kernel.load loads file from current directory without '.' in path — misharinn@...
Issue #16988 has been reported by TheSmartnik (Nikita Misharin).
5 messages
2020/06/26
[#98969] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings — marcandre-ruby-core@...
Issue #16994 has been reported by marcandre (Marc-Andre Lafortune).
7 messages
2020/06/26
[#100117] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings
— matz@...
2020/09/25
Issue #16994 has been updated by matz (Yukihiro Matsumoto).
[ruby-core:98865] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
From:
mame@...
Date:
2020-06-18 09:37:38 UTC
List:
ruby-core #98865
Issue #16456 has been updated by mame (Yusuke Endoh).
Adding a new type of parameters will break existing code. In fact, if we add a new type `:delegate`, the Sorbet code written in #note-8 will `raise "Unknown parameter type: #{type}"`. So, we must be careful.
Currently, `(...)` parameter generates a unique indicator `[:rest, :*]`. Note that it uses an invalid variable name `:*`, so it is not produced by other parameters than `(...)`. Thus, without ambiguity, it is already able to determine if `(...)` parameter is used or not by checking if the result of `Method#parameters` includes `[:rest, :*]`. So, currently, I don't see a strong reason to add a new type.
That being said, feeling is important for Ruby. Changing `:*` to `:"..."` may be acceptable, though it brings incompatibility. I have no idea if it is worth or not.
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-86230
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
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>