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

[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:123021] [Ruby Misc#21549] DevMeeting-2025-09-11
by mame (Yusuke Endoh) 21 Aug '25

21 Aug '25

Issue #21549 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21549: DevMeeting-2025-09-11 https://bugs.ruby-lang.org/issues/21549 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/09/11 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/09/08. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

1 0

[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:122665] [Ruby Bug#21503] \p{Word} does not match on \p{Join_Control} while docs say it does
by procmarco (Marco Concetto Rudilosso) 21 Aug '25

21 Aug '25

Issue #21503 has been reported by procmarco (Marco Concetto Rudilosso). ---------------------------------------- Bug #21503: \p{Word} does not match on \p{Join_Control} while docs say it does https://bugs.ruby-lang.org/issues/21503 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * ruby -v: 3.4.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- in the [docs](https://ruby-doc.org/3.4.1/Regexp.html#:~:text=/%5Cp%7B-,Word,-%7D/%3… it is mentioned that `\p{Word}` matches the equivalent of: `[\p{M}\p{Nd}\p{Pc}\p{Alpha}\p{Join_Control}]` as it's also defined in the [unicode spec](https://unicode.org/reports/tr18/#word) the issue is that it does not seem to be the case ``` irb(main):018> REGEX = /\p{Word}/u => /\p{Word}/ irb(main):019> "\u200D".gsub(REGEX, "-") => "‍" irb(main):020> REGEX2 = /\p{Join_Control}/u => /\p{Join_Control}/ irb(main):021> "\u200D".gsub(REGEX2, "-") => "-" ``` There's 2 solutions here, either we change the docs or the code. -- https://bugs.ruby-lang.org/

5 6

[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

[ruby-core:122898] [Ruby Feature#21527] Proposal: Math.log1p and Math.expm1
by mame (Yusuke Endoh) 21 Aug '25

21 Aug '25

Issue #21527 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21527: Proposal: Math.log1p and Math.expm1 https://bugs.ruby-lang.org/issues/21527 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Let's add `Math.log1p` and `Math.expm1`. * `Math.log1p(x)`: Computes `Math.log(x + 1)` * `Math.expm1(x)`: Computes `Math.exp(x) - 1` These methods are often more accurate than the straightforward computation, especially when `x` is close to zero. ``` # The current approach loses precision p Math.log(1 + 1.0e-16) #=> 0.0 p Math.exp(1.0e-16) - 1 #=> 0.0 # The proposed methods return the accurate result p Math.log1p(1.0e-16) #=> 1.0e-16 p Math.expm1(1.0e-16) #=> 1.0e-16 ``` Note that they are very standard; the C99 even defines `log1p()` and `expm1()`. Other major programming languages (Python, JavaScript, Java, Go, Rust, etc.) also provide them. PR: https://github.com/ruby/ruby/pull/14087 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122899] [Ruby Bug#21528] SyntaxError#message may have broken encoding with multibyte source under Prism
by alpaca-tc (Hiroyuki Ishii) 21 Aug '25

21 Aug '25

Issue #21528 has been reported by alpaca-tc (Hiroyuki Ishii). ---------------------------------------- Bug #21528: SyntaxError#message may have broken encoding with multibyte source under Prism https://bugs.ruby-lang.org/issues/21528 * Author: alpaca-tc (Hiroyuki Ishii) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Since the introduction of Prism, when parsing Ruby source code that contains multibyte characters, SyntaxError#message can sometimes have invalid encoding. Here is a reproducible example: ``` begin RubyVM::InstructionSequence.compile(<<~CODE, nil, nil, 1) if a # 0000000000000ああああああ # CODE rescue SyntaxError => e $e = e puts e.message # string contains a multibyte character that is cut off mid-byte. \xE3 # <compiled>:3: syntax errors found # 1 | if a # > 2 | # 0000000000000あああああ\xE3 ... # | ^ expected an `end` to close the conditional clause # > 3 | # # | ^ unexpected end-of-input, assuming it is closing the parent top level context puts e.message.valid_encoding? #=> expected true, but got false end ``` This appears to be caused by a truncation process in prism's error message generating that does not consider multibyte character boundaries. See: The truncation logic around [prism_compile.c L10696-L10709](https://github.com/ruby/ruby//blob/30a20bc166bc37acd7dcb3788… I'm not sure how to correctly fix it due to lack of knowledge about safe byte truncation. I discovered this issue through irb, which attempts to display source code even when it contains syntax errors. Because irb uses `SyntaxError#message`, it raised an `ArgumentError: invalid byte sequence in UTF-8`. See: https://github.com/ruby/irb/blob/f60dfa8549f746f69e9a6d160604a7a4974ffac1/l… If this is considered an irb issue, I already have a patch for IRB that handles it. -- https://bugs.ruby-lang.org/

4 3