- ruby-core - ml.ruby-lang.org

[ruby-core:123036] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). The single-character syntax itself isn't a problem if limited to instance variables. `foo ?=` is already valid and shouldn't change, but `@foo ?=` isn't currently valid, so it could serve as "assign if ivar undefined." The problem is consistency. All operator-equals decompose uniformly (`a += b` -> `a = a + b`) but `?=` and its variations (like `@||=`) would be very different. What should happen with cases like: ```ruby foo ?= expr foo[key] ?= expr foo.bar ?= expr ``` If that's a syntax error, it's inconsistent with other operators like `+=` or `||=`. If it means "assign if not nil", it's inconsistent with `@foo ?= expr` as "assign if undefined". And if `@foo ?= expr` is changed to mean "assign if not nil" then we're back to the nil coalescing operator which is a different topic (#13820) An operator for "assign if undefined" is appealing, but the implications don't work out cleanly. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114347 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117216] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
by forthoney (Seong-Heon Jung) 21 Aug '25

21 Aug '25

Issue #20346 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346 * Author: forthoney (Seong-Heon Jung) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper def initialize @ractor = Ractor.new do Ractor.recv # Ractor doesn't start until explicitly told to # Do some calculations fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) } fib.call(20) end end def take_async @ractor.send(nil) Thread.new { @ractor.take }.join.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever
by luke-gru (Luke Gruber) 21 Aug '25

21 Aug '25

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123030] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). Currently, `?=` means "a single character =". We don't want to break current available syntax, unless absolutely necessary. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114340 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123028] [Ruby Feature#17316] On memoization
by matheusrich (Matheus Richard) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matheusrich (Matheus Richard). @matz I propose `?=` as the uninitialized assignment operator: ```rb @foo ?= some_heavy_calculation(...) ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114338 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122987] [Ruby Bug#21547] SEGV after 2083fa commit
by watson1978 (Shizuo Fujita) 21 Aug '25

21 Aug '25

Issue #21547 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #21547: SEGV after 2083fa commit https://bugs.ruby-lang.org/issues/21547 * Author: watson1978 (Shizuo Fujita) * Status: Open * Target version: 3.5 * ruby -v: ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am maintaining [Fluentd](https://github.com/fluent/fluentd). When I run Fluentd's unit tests after [2083fa](https://github.com/ruby/ruby/commit/2083fa89fc29005035c1a098185c4b7… commit, Ruby causes SEGV. ``` $ git clone --depth 1 https://github.com/fluent/fluentd.git $ cd fluentd $ bundle install $ ruby -v ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] $ bundle exec rake test TESTOPTS=-v TEST=test/plugin/test_in_exec.rb Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/.rbenv/versions/3.5-debug/bin/ruby -w -I"lib:test" -Eascii-8bit:ascii-8bit /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader.rb "test/plugin/test_in_exec.rb" -v Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - tag /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - time /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:246: warning: assigned but unused variable - d /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: method redefined; discarding old inherited /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: previous definition of inherited was here Loaded suite /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader Started ExecInputTest: test: emit error message with read_with_stderr: .: (0.229405) test: emit with formats[default]: .: (0.908338) test: emit with formats[json]: .: (0.809623) test: emit with formats[msgpack]: /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105: [BUG] Segmentation fault at 0x0000000000000024 ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0054 p:---- s:0316 e:000315 CFUNC :detach c:0053 p:---- s:0313 e:000312 CFUNC :detach c:0052 p:0012 s:0309 e:000308 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105 [FINISH] c:0051 p:---- s:0304 e:000303 CFUNC :reverse_each c:0050 p:0006 s:0300 e:000299 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:102 [FINISH] c:0049 p:---- s:0297 e:000296 CFUNC :synchronize c:0048 p:0006 s:0293 e:000292 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:101 c:0047 p:0014 s:0289 e:000288 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/child_process.rb:149 c:0046 p:0011 s:0283 e:000282 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/parser.rb:126 c:0045 p:0016 s:0279 e:000278 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0044 p:0005 s:0276 e:000275 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:150 c:0043 p:0064 s:0270 E:001588 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0042 p:0123 s:0263 E:0022e0 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:100 c:0041 p:0045 s:0250 E:0003a8 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base_owner.rb:130 c:0040 p:0028 s:0239 e:000238 BLOCK /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:272 c:0039 p:0131 s:0229 e:000228 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:911 c:0038 p:0003 s:0221 e:000220 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:601 c:0037 p:0024 s:0218 e:000217 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0036 p:0024 s:0214 e:000213 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0035 p:0024 s:0210 e:000209 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0034 p:0052 s:0206 e:000205 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:257 c:0033 p:0009 s:0197 e:000196 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:292 c:0032 p:0004 s:0192 E:000318 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:599 [FINISH] c:0031 p:---- s:0188 e:000187 CFUNC :catch c:0030 p:0046 s:0184 E:001d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:598 c:0029 p:0045 s:0175 E:001730 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0028 p:0013 s:0163 e:000162 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0027 p:---- s:0159 e:000158 CFUNC :each c:0026 p:0009 s:0155 e:000154 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0025 p:0037 s:0147 e:000146 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0024 p:0030 s:0139 E:000ce8 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0023 p:0045 s:0130 E:000090 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0022 p:0013 s:0118 e:000117 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0021 p:---- s:0114 e:000113 CFUNC :each c:0020 p:0009 s:0110 e:000109 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0019 p:0037 s:0102 e:000101 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0018 p:0030 s:0094 E:001318 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0017 p:0028 s:0085 E:0015a0 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:72 c:0016 p:0041 s:0079 e:000078 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:49 [FINISH] c:0015 p:---- s:0075 e:000074 CFUNC :catch c:0014 p:0004 s:0071 e:000070 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:44 c:0013 p:0008 s:0067 e:000066 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:19 c:0012 p:0006 s:0063 e:000062 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:43 c:0011 p:0038 s:0060 E:002668 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:107 c:0010 p:0033 s:0051 E:000d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:42 c:0009 p:0006 s:0044 e:000043 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:40 c:0008 p:0019 s:0040 e:000039 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:25 c:0007 p:0015 s:0036 e:000035 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnerutilities.rb:24 c:0006 p:0010 s:0030 e:000029 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:499 c:0005 p:0019 s:0027 e:000026 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:564 c:0004 p:0182 s:0022 e:000021 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:498 c:0003 p:0057 s:0016 e:000015 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:68 c:0002 p:0017 s:0007 e:000005 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit.rb:518 [FINISH] c:0001 p:0000 s:0003 E:000410 DUMMY [FINISH] ...(snip)... ``` -- https://bugs.ruby-lang.org/

3 9

[ruby-core:122900] [Ruby Bug#21529] Deprecate the /o modifier and warn against using it
by jpcamara (JP Camara) 21 Aug '25

21 Aug '25

Issue #21529 has been reported by jpcamara (JP Camara). ---------------------------------------- Bug #21529: Deprecate the /o modifier and warn against using it https://bugs.ruby-lang.org/issues/21529 * Author: jpcamara (JP Camara) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I recently ran into a bug in some code because it was using the /o modifier as an optimization, not realizing it created a permanent, immutable value after the first time it gets evaluated. I dug into how the modifier works in CRuby and the history of it here: https://jpcamara.com/2025/08/02/the-o-in-ruby-regex.html. The feature seems like a total footgun with almost no upside. If I run a benchmark between a local regex, and a regex cached by /o, there is no real difference. ```rb require "benchmark" def letters "A-Za-z" end words = %w[the quick brown fox jumped over the lazy dog] Benchmark.bm do |bm| bm.report("without /o:") do regex = /\A[A-Za-z]+\z/ words.each do |word| word.match(regex) end end bm.report("with /o: ") do words.each do |word| word.match(/\A[#{letters}]+\z/o) end end end ``` Most of the time I found that "without /o" actually came out ahead. ``` user system total real without /o: 0.000019 0.000003 0.000022 ( 0.000014) with /o: 0.000020 0.000001 0.000021 ( 0.000020) ``` I'd like to deprecate the feature and update the docs to warn against using it. I'd be happy to submit a PR doing that. Thanks! -- https://bugs.ruby-lang.org/

6 9

[ruby-core:123013] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #12282 has been updated by matz (Yukihiro Matsumoto). `fetch_path` is much better than `dig!` since this bang method is against our naming convention (if we have x and x!, a method with `!` (bang) should be more dangerous). At the same time, `_path` usually means file paths in Ruby, and possibly cause confusion, although **I** understand `path` here is totally valid. Matz. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114317 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 21 Aug '25

21 Aug '25

Issue #21520 has been reported by nuzair46 (Nuzair Rasheed). ---------------------------------------- Feature #21520: Feature Proposal: Enumerator::Lazy#peek https://bugs.ruby-lang.org/issues/21520 * Author: nuzair46 (Nuzair Rasheed) * Status: Open ---------------------------------------- # Abstract Add a #peek method to Enumerator::Lazy that allows observing each element in a lazy enumeration pipeline without modifying or consuming the stream. # Background Ruby provides Enumerator::Lazy for efficient lazy stream processing. However, unlike languages such as Java, it lacks a clean way to inspect intermediate elements during lazy evaluation. Currently, developers must misuse .map for side effects, example: ```rb (1..).lazy.map { |x| puts x; x }.select(&:even?).first(3) ``` This is semantically incorrect and confusing, since .map implies transformation, not observation. # Proposal Introduce Enumerator::Lazy#peek, which yields each item to a block and returns the item unmodified, similar to Object#tap, but in a lazy stream: ```rb (1..).lazy .peek { |x| puts "saw: #{x}" } .select(&:even?) .first(3) ``` This would be equivalent to: ```rb lazy.map { |x| block.call(x); x } ``` but with improved semantic clarity. # Use cases • Debugging lazy enumerators without breaking the chain • Logging or instrumentation in pipelines • Educational / demo use for showing lazy evaluation step-by-step • Cleaner replacement for map { puts x; x } hacks Example: ```rb data = (1..).lazy .peek { |x| puts "got #{x}" } .select(&:even?) .first(5) ``` result: ```rb got 1 got 2 got 3 got 4 got 5 ``` And return [2, 4, 6, 8, 10] # Discussion #peek is a minimal, non-breaking addition that improves clarity and idiomatic usage of Enumerator::Lazy. It avoids abusing .map for observation and is familiar to developers from other languages. #peek is also not needed for other enumerators where .tap or .each can do the job. It mirrors Java’s .stream().peek(...) and makes Ruby’s lazy enumeration more expressive and readable. # See also • [Java Stream.peek](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Str… I would be glad to work on this and make a PR. Thank you. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:123006] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). I understand the motivation, but the proposed "@||=" is unacceptable. Other suggestions were made, but I don't think any of them adequately express the intent. If there are no good operator name suggestions in the future, it would be better to explicitly use `defined?`. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114308 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0