[#106355] [Ruby master Bug#18373] RBS build failure: '/include/x86_64-linux/ruby/config.h', needed by 'constants.o'. — "vo.x (Vit Ondruch)" <noreply@...>

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

28 messages 2021/12/01

[#106356] [Ruby master Bug#18374] make: Circular spec/ruby/optional/capi/ext/array_spec.c <- spec/ruby/optional/capi/ext/array_spec.c dependency dropped. — "vo.x (Vit Ondruch)" <noreply@...>

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

8 messages 2021/12/01

[#106360] [Ruby master Feature#18376] Version comparison API — "vo.x (Vit Ondruch)" <noreply@...>

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

28 messages 2021/12/01

[#106543] [Ruby master Bug#18396] An unexpected "hash value omission" syntax error when parentheses call expr follows — "koic (Koichi ITO)" <noreply@...>

Issue #18396 has been reported by koic (Koichi ITO).

10 messages 2021/12/08

[#106596] [Ruby master Misc#18399] DevMeeting-2022-01-13 — "mame (Yusuke Endoh)" <noreply@...>

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

11 messages 2021/12/09

[#106621] [Ruby master Misc#18404] 3.1 documentation problems tracking ticket — "zverok (Victor Shepelev)" <noreply@...>

Issue #18404 has been reported by zverok (Victor Shepelev).

16 messages 2021/12/11

[#106634] [Ruby master Bug#18407] Behavior difference between integer and string flags to File creation — deivid <noreply@...>

Issue #18407 has been reported by deivid (David Rodr鱈guez).

12 messages 2021/12/13

[#106644] [Ruby master Bug#18408] Rightward assignment into instance variable — "Dan0042 (Daniel DeLorme)" <noreply@...>

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

23 messages 2021/12/13

[#106686] [Ruby master Bug#18409] Crash (free(): invalid pointer) if LD_PRELOAD doesn't explicitly include libjemalloc.so.2 — "itay-grudev (Itay Grudev)" <noreply@...>

Issue #18409 has been reported by itay-grudev (Itay Grudev).

7 messages 2021/12/15

[#106730] [Ruby master Bug#18417] IO::Buffer problems — "zverok (Victor Shepelev)" <noreply@...>

Issue #18417 has been reported by zverok (Victor Shepelev).

9 messages 2021/12/19

[#106784] [CommonRuby Feature#18429] Configure ruby-3.0.3 on Solaris 10 Unknown keyword 'URL' in './ruby.tmp.pc' — "dklein (Dmitri Klein)" <noreply@...>

Issue #18429 has been reported by dklein (Dmitri Klein).

32 messages 2021/12/23

[#106828] [Ruby master Bug#18435] Calling `protected` on ancestor method changes result of `instance_methods(false)` — "ufuk (Ufuk Kayserilioglu)" <noreply@...>

Issue #18435 has been reported by ufuk (Ufuk Kayserilioglu).

23 messages 2021/12/26

[#106833] [Ruby master Feature#18438] Add `Exception#additional_message` to show additional error information — "mame (Yusuke Endoh)" <noreply@...>

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

30 messages 2021/12/27

[#106834] [Ruby master Bug#18439] Support YJIT for VC++ — "usa (Usaku NAKAMURA)" <noreply@...>

Issue #18439 has been reported by usa (Usaku NAKAMURA).

11 messages 2021/12/27

[#106851] [Ruby master Bug#18442] Make Ruby 3.0.3 on Solaris 10 with "The following command caused the error: cc -D_STDC_C99= " — "dklein (Dmitri Klein)" <noreply@...>

Issue #18442 has been reported by dklein (Dmitri Klein).

8 messages 2021/12/27

[#106928] [Ruby master Bug#18454] YJIT slowing down key Discourse benchmarks — "sam.saffron (Sam Saffron)" <noreply@...>

Issue #18454 has been reported by sam.saffron (Sam Saffron).

8 messages 2021/12/31

[ruby-core:106601] [Ruby master Feature#18351] Support anonymous rest and keyword rest argument forwarding

From: "jeremyevans0 (Jeremy Evans)" <noreply@...>
Date: 2021-12-09 15:38:19 UTC
List: ruby-core #106601
Issue #18351 has been updated by jeremyevans0 (Jeremy Evans).


mame (Yusuke Endoh) wrote in #note-3:
> The concern about `Method#parameters` should be discussed after Ruby 3.1 is released. Now `Method#parameters` of `def foo(...)` returns `[[:rest, :*], [:keyrest, :**], [:block, :&]]`. After this change, perhaps it would be unable to distinguish between `def foo(...)` and `def foo(*, **, &)`. But, I have no idea whether we should be able to distinguish them.

I don't think there is a need to distinguish them.  In both the `foo(...)` and `def foo(*, **, &)` cases, the method accepts the same parameters (all normal parameters, all keyword parameters, and a block).  You have no idea what the method is doing with the arguments.  In both cases, the method can ignore the arguments, or delegate them.  `foo(*, **, &)` is more flexible in that it can delegate the arguments separately, which `foo(...)` cannot do, but that's an implementation detail of the method, not what arguments it accepts (which is what Method#parameters returns).

It is possible to choose different names for the `*` and `**` anonymous parameters, and recognize those names and keep Method#parameters output the same as it currently is, but I think the behavior in the current PR is better.  Can anyone show a problem with having Method#parameters for `foo(...)` and `def foo(*, **, &)` return the same result?

----------------------------------------
Feature #18351: Support anonymous rest and keyword rest argument forwarding
https://bugs.ruby-lang.org/issues/18351#change-95268

* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
I would like to add support for the following syntax:

```ruby
def foo(*)
  bar(*)
end
def baz(**)
  quux(**)
end
```

This is a natural addition after the introduction of anonymous block forwarding.  Anonymous rest and keyword rest arguments were already supported in method parameters, this just allows them to be used as arguments to other methods.  The same advantages of anonymous block forwarding apply to rest and keyword rest argument forwarding.

I've submitted a pull request implementing this syntax: https://github.com/ruby/ruby/pull/5148



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