Issue #19324 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19324: Enumerator.product => Enumerable#product
https://bugs.ruby-lang.org/issues/19324
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I know it might be too late after introducing a feature and releasing a version, but I find `Enumerator.product` quite confusing, and can't find any justification in #18685.
**Problem 1: It is `Array#product` but `Enumerator.product`**
```ruby
[1, 2].product([4, 5])
# => [[1, 4], [1, 5], [2, 4], [2, 5]]
# Usually, when we add methods to Enumerable/Enumerator which
# already array had before, it is symmetric, say...
[1, nil, 2, 3].compact #=> [1, 2, 3]
[1, nil, 2, 3].lazy.compact.first(2) #=> [1, 2]
# But not in this case:
[1, 2].lazy.product([4, 5]).first(2)
# undefined method `product' for #<Enumerator::Lazy: [1, 2]> (NoMethodError)
# Because you "just" need to change it to:
Enumerator.product([1, 2].lazy, [4, 5]).first(2)
# => [[1, 4], [1, 5]]
```
No other method was "promoted" from Array this way
And in general, I believe core methods tend to belong to the first object in the expression and not be free module methods, Elixir style.
**Problem 2: It is one letter different from `Enumerator.produce`**
I understand I might be biased here (as a person who proposed `produce`), and that method is not as popular (yet?) as I hoped, but still, two methods that do completely different things and differ by one letter, both being somewhat vague verbs (so it is easy to confuse them unless you did a lot of math and "product" is firmly set for set product in your head).
I believe that EITHER of two problems would be concerning enough, but the combination of them seems to be a strong enough argument to make the change?.. (Maybe with graceful deprecation of module method in one next version, but, considering the Ruby 3.2 is just released, maybe vice versa, fix the problem in the next minor release?..)
--
https://bugs.ruby-lang.org/
Issue #19370 has been reported by zverok (Victor Shepelev).
----------------------------------------
Feature #19370: Anonymous parameters for blocks?
https://bugs.ruby-lang.org/issues/19370
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
Just to clarify: are anonymous parameters delegation is planned to support in blocks?
It would be a nice addition, if it is possible to implement:
```ruby
# data in form [request method, URL, params]:
[
[:get, 'https://google.com', {q: 'Ruby'}, {'User-Argent': 'Google-Chrome'}],
[:post, 'https://gist.github.com', 'body'],
# ...
].each { |method, *| request(method.to_s.upcase, *) }
```
...and at the very least, consistent with what the method definition can have.
If they are NOT planned to be implemented, I believe that at least error messages should be made much clearer, because currently, this would happen while running the code above:
> no anonymous rest parameter (SyntaxError)
I understand the reason (the `request` clause doesn't "see" anonymous parameter of the **block**, and claims that current **method** doesn't have them), but it looks honestly confusing and inconsistent.
--
https://bugs.ruby-lang.org/
Issue #19977 has been reported by kyanagi (Kouhei Yanagita).
----------------------------------------
Bug #19977: (nil..nil) === x can raise an exception, differing from Range#cover?
https://bugs.ruby-lang.org/issues/19977
* Author: kyanagi (Kouhei Yanagita)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I investigated Range#=== and Range#cover?, and found that the only difference in behavior between them would be that
`(nil..nil) === x` could throw an exception.
```
% ~/tmp/ruby-master/bin/ruby -v
ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22]
```
```
% ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil) === "a"'
-e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError)
p (nil..nil) === "a"
^^^
from -e:1:in `<main>'
```
```
% ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil).cover?("a")'
true
```
Is this difference intended?
According to NEWS, `Range#===` uses `cover?` since Ruby 2.6 (For `String`, since Ruby 2.7).
Following this, `(nil..nil) === x` should not throw an exception in the same way as `(nil..nil).cover?(x)`.
history:
`(nil..nil) === "a"` throws an exception since https://github.com/ruby/ruby/commit/04a92a6.
For "linear objects" (`Integer`, `Float`, `Numeric`, `Time`), it has beed fixed not to throw an exception on https://github.com/ruby/ruby/commit/fb17c83.
related issues:
* [Bug #15449] Range#=== is not using cover in Ruby 2.6
* [Bug #18580] Range#include? inconsistency for beginless String ranges
* [Bug #19533] Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2
--
https://bugs.ruby-lang.org/
Issue #19683 has been reported by jeremyevans0 (Jeremy Evans).
----------------------------------------
Bug #19683: ruby-3.3.0-preview1 does not build with BSD make without --with-baseruby
https://bugs.ruby-lang.org/issues/19683
* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [x86_64-openbsd7.3]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
ruby-3.3.0-preview1 does not build with BSD make without `--with-baseruby`. However, it builds fine with GNU make and when using BSD make with `--with-baseruby`. Previous Ruby tarball releases have built fine with BSD make without `--with-baseruby`, so this issue has been introduced recently.
When building with BSD make without `--with-baseruby`, building fails after generating RI format with:
```
/bin/sh: false: not found
*** Error 127 in . (exts.mk:94 'ruby': @make UPDATE_LIBRARIES=no EXTENCS=dmyenc.o BASERUBY=echo\ executable\ host\ ruby\ is\ required.\ \ ...)
*** Error 2 in /home/jeremy/local/ruby-3.3.0-preview1 (Makefile:948 'build-ext': @make -f exts.mk libdir="/usr/local/lib" LIBRUBY_EXTS=./...)
```
--
https://bugs.ruby-lang.org/
Issue #19326 has been reported by sdwolfz (Codruț Gușoi).
----------------------------------------
Feature #19326: Please add a better API for passing a Proc to a Ractor
https://bugs.ruby-lang.org/issues/19326
* Author: sdwolfz (Codruț Gușoi)
* Status: Open
* Priority: Normal
----------------------------------------
Example 1:
```ruby
class Worker
def initialize(&block)
@block = block
end
def run
Ractor.new(@block, &:call)
end
end
worker = Worker.new { 1 }
puts worker.run.take
```
Errors with:
```
<internal:ractor>:271:in `new': allocator undefined for Proc (TypeError)
from scripts/run.rb:9:in `run'
from scripts/run.rb:14:in `<main>'
```
Example 2:
```ruby
class Worker
def initialize(&block)
@block = Ractor.make_shareable(block)
end
def run
Ractor.new(@block, &:call)
end
end
worker = Worker.new { 1 }
puts worker.run.take
```
Errors with:
```
<internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError)
from scripts/run.rb:5:in `initialize'
from scripts/run.rb:13:in `new'
from scripts/run.rb:13:in `<main>'
```
Example 3:
```ruby
class Worker
def initialize(&block)
@block = Ractor.make_shareable(block)
end
def run
Ractor.new(@block, &:call)
end
end
worker = Ractor.current.instance_eval { Worker.new { 1 } }
puts worker.run.take
```
Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker.
I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better.
The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter.
The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation).
--
https://bugs.ruby-lang.org/
Issue #19980 has been reported by mdalessio (Mike Dalessio).
----------------------------------------
Misc #19980: Is the Ruby 3.3 ABI frozen?
https://bugs.ruby-lang.org/issues/19980
* Author: mdalessio (Mike Dalessio)
* Status: Open
* Priority: Normal
----------------------------------------
I'm a co-maintainer of [rake-compiler-dock](https://github.com/rake-compiler/rake-compiler-dock) which is used to build precompiled native packages for some gems, including nokogiri, sqlite3, grpc, re2, and ruby-magic.
In the past, precompiled native gems generally released support for a new version of Ruby days or weeks after Ruby's release (for example, [Nokogiri v1.14.0 released on 2023-01-12](https://nokogiri.org/CHANGELOG.html)). In some cases, the lack of native gem support has slowed user adoption of the new version of Ruby.
This year, I'd like to see native gems release Ruby 3.3 support before the final version is released. This will encourage testing of Ruby 3.3 previews and allow users to immediately upgrade to Ruby 3.3 final when it is released.
To do that, I would like to cut a release of the rake-compiler-dock gem (and its [build containers](https://github.com/rake-compiler/rake-compiler-dock/pkgs/contai…) that supports Ruby 3.3 as soon as possible (I already have a feature branch mostly working based on 3.3.0_preview1 at https://github.com/rake-compiler/rake-compiler-dock/pull/105).
Is the Ruby 3.3 ABI frozen now? If I build a native gem against Ruby 3.3.0_preview2, is there any reason to believe that it wouldn't work with Ruby 3.3 final when it is released?
Thank you for any guidance you can provide.
--
https://bugs.ruby-lang.org/
Issue #19877 has been reported by tompng (tomoya ishida).
----------------------------------------
Bug #19877: Non intuitive behavior of syntax only applied to literal value
https://bugs.ruby-lang.org/issues/19877
* Author: tompng (tomoya ishida)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.3.0dev (2023-09-08T23:08:32Z master b635a66e95) [x86_64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Non intuitive behavior of syntax only applied to literal value
Some ruby syntax is only applied to literal value.
~~~ruby
def 1.foo; end # receiver is a literal, it is Syntax Error
/(?<a>)/ =~ s # receiver is regexp literal, it will assign to local variable
if cond1..cond2; end # range-like syntax appears in condition, it is flipflop
~~~
If it is wrapped with parenthesis, the behavior seems not intuitive for me, and YARP parses it differently.
~~~ruby
def (1).foo; end # Syntax Error
def ((1;1)).foo; end # Syntax Error
def ((;1)).foo; end # Syntax OK
def ((1+1;1)).foo; end # Syntax OK
def ((%s();1)).foo; end # Syntax Error
def ((%w();1)).foo; end # Syntax OK
def ("#{42}").foo; end # Syntax Error
def (:"#{42}").foo; end # Syntax OK
(/(?<a>)/) =~ s # assigns to a
(;/(?<a>)/) =~ s # does not assigns
(%s();/(?<a>)/) =~ s # assigns to a
(%w();/(?<a>)/) =~ s # does not assigns
(1; (2; 3; (4; /(?<a>)/))) =~ s # assigns to a
(1+1; /(?<a>)/) =~ s # does not assign
if ((cond1..cond2)); end # flipflop
if (; cond1..cond2); end # range
if (1; cond1..cond2); end # flipflop
if (%s(); cond1..cond2); end # flipflop
if (%w(); cond1..cond2); end # range
if (1; (2; (3; 4; cond1..cond2))); end # flipflop
if (1+1; cond1..cond2); end # range
~~~
I expect YARP and parse.y parses same.
I expect all parenthesis-wrapped result same.
I think it is simple and intuitive if parenthesis-wrapped code always behaves different from non-wrapped code because there are more complex variation like this
~~~ruby
def (class A; 1; end).foo; end
(break; /?<a>/) =~ s
class A; /?<a>/; end =~ s
~~~
--
https://bugs.ruby-lang.org/