June 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125124] [Ruby Bug#21964] Fiber stack acquire can expand unnecessarily.
by ioquatix (Samuel Williams) 14 Jun '26

14 Jun '26

Issue #21964 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21964: Fiber stack acquire can expand unnecessarily. https://bugs.ruby-lang.org/issues/21964 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- In several common scenarios, the fiber stack allocator can choose to expand the fiber stack pool even when there are unreachable (effectively dead) fibers. For example, the following program will eventually crash if GC does not run in time: ```ruby loop do Fiber.new{Fiber.yield}.resume end ``` We have a loop that resumes a fiber, that fiber yields, and then becomes unreachable. Eventually, we will exhaust the OS vm map limit and fail with `FiberError`. However, at most only one fiber (stack) is needed to execute the above program, since the fiber immediately becomes unreachable. To fix this, we run GC before trying to expand the fiber stacks. In practice, fiber stacks are expanded on power of 2, up to 1024 fibers per allocation. So GC is only run in scenarios where we hit this limit. If GC is running normally, or fibers are terminating normally, we may never hit this code path. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 14 Jun '26

14 Jun '26

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

8 25

[ruby-core:125728] [Ruby Bug#22109] Unexpected or misleading error when subclass of a ractor calls a new method on itself
by miles-georgi (Miles Georgi) 13 Jun '26

13 Jun '26

Issue #22109 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22109: Unexpected or misleading error when subclass of a ractor calls a new method on itself https://bugs.ruby-lang.org/issues/22109 * Author: miles-georgi (Miles Georgi) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey hey! When I run the following code: ```ruby class SubRactor < Ractor attr_accessor :foo end SubRactor.new { puts foo }.join ``` I get the following error: ``` can not access instance variables of shareable objects from non-main Ractors (Ractor::IsolationError) ``` Unclear if I shouldn't get an error of any sort in this situation, but if this is a legitimate error situation, this error seems inaccurate since Ractors can obviously access instance variables of shareable objects. A tiny script that shows that: ```ruby class C attr_accessor :foo def initialize = self.foo = 100 INSTANCE = new.freeze end raise "not shareable!" unless Ractor.shareable?(C::INSTANCE) Ractor.new { puts C::INSTANCE.foo }.join ``` This prints out 100 as expected instead of giving that error. This happens on both: ruby 4.1.0dev (2026-06-11T14:25:18Z master 8e8682fc23) +PRISM [x86_64-linux] and ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] The script is so puny seems I shouldn't upload the file but let me know if I should just always upload a script file when filing these even when they are trivially small. Cheers! -- https://bugs.ruby-lang.org/

3 5

[ruby-core:125243] [Ruby Bug#21994] If there is a local variable `foo`, calls to a method `foo` with a regexp literal as first argument is always a SyntaxError without parentheses
by jneen (Jeanine Adkisson) 13 Jun '26

13 Jun '26

Issue #21994 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21994: If there is a local variable `foo`, calls to a method `foo` with a regexp literal as first argument is always a SyntaxError without parentheses https://bugs.ruby-lang.org/issues/21994 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Quick version: ```bash ruby -e 'p /hello/' # => /hello/ (warning) ruby -e 'p = 1; p /hello/' # syntax error ruby -e 'p %r/hello/' # => /hello/ (no warning) ruby -e 'p = 1; p %r/hello/' # syntax error ``` ## Context In Rouge, our lexing DSL originally looked like this: ```ruby rule /some_regex/, Some::TokenType, :next_state rule /some_other_regex/ do |match| # custom action end ``` In a DSL context like this, I feel that using parentheses for *every* rule definition is a hassle and looks bad, so we leave them off, as is convention. Unfortunately, this warns: ``` warning: ambiguous `/`; wrap regexp in parentheses or add a space after `/` operator ``` Some time ago, to reduce warning-spam on users who run with `-w`, we transitioned all of these to use `%r/.../` or `%r(...)` syntax, which does not warn. The issue here I think is that *both* cases are equivalently ambiguous in some sense, which becomes apparent with the local-scope-dependent behaviour of the parser (putting aside that dependency on local variable scope makes the Ruby syntax highlighting of Rouge more or less impossible to do correctly without a full parse). If there is a local variable named `rule` introduced at any point, even several block scopes above, the entire file errors out in a very confusing manner. At the very least, I feel that the warnings here are inconsistent. If both cases truly are ambiguous and dependent on local variable scope, perhaps it would be better to warn on both - though that would make using a regex literal as a first argument *always* require parentheses to avoid warnings, which would make my DSL much harder. I'm honestly not entirely sure what a good solution would be, but I would like to open a discussion on the topic. Perhaps philosophically related to the other bug I have open ( #21870 ) - is this truly worthy of a warning, or should this be a linter concern? -- https://bugs.ruby-lang.org/

5 7

[ruby-core:125740] [Ruby Feature#13677] Add more details to error "Name or service not known (SocketError)"
by akr (Akira Tanaka) 13 Jun '26

13 Jun '26

Issue #13677 has been updated by akr (Akira Tanaka). I think it is better for error messages to start with a fixed string, since that makes them easier to search for mechanically. Therefore, I do not like the current proposed patch (which inserts the hostname between reason and gai_strerror). Also, the glibc error message "Name or service not known" indicates that not only the hostname but also the service (port) may be incorrect. We should probably display the service as well. With that in mind, how about something like the following? ``` getaddrinfo: Name or service not known "unknown.domain":80 (Socket::ResolutionError) getaddrinfo: Name or service not known. "unknown.domain":80 (Socket::ResolutionError) ``` It uses the inspect method on the hostname string so that it is enclosed in double quotes. I believe the resulting message remains reasonably understandable regardless of whether the error message returned by gai_strerror ends with a period or not. In addition, even if the host contains control characters, the inspect method converts them into visible characters. ---------------------------------------- Feature #13677: Add more details to error "Name or service not known (SocketError)" https://bugs.ruby-lang.org/issues/13677#change-117626 * Author: dsbonev (Dimitar Bonev) * Status: Open ---------------------------------------- ruby version: `ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]` ruby script: ~~~ ruby require 'socket' TCPSocket.new 'nonexistent.example.com', 80 ~~~ Result: `getaddrinfo: Name or service not known (SocketError)` Expected: `getaddrinfo: Name or service not known for nonexistent.example.com (SocketError)` Why: This will make it easier to resolve errors of this kind by just looking at the logged messages. It is common for production and non-production (development, test) code to connect to different hosts which can produce errors due to wrong configuration. This change will make the ruby stdlib code more consistent as other methods already provide useful error information. Some examples: ~~~ ruby host = 'nonexistent.example.com'; port = 80 Resolv.getaddress host # => Resolv::ResolvError: no address for nonexistent.example.com Socket.getservbyname host # => SocketError: no such service nonexistent.example.com/tcp Net::HTTP.get Struct.new(:hostname, :port, :scheme).new(host, port, 'http') # => SocketError: Failed to open TCP connection to nonexistent.example.com:80 (getaddrinfo: Name or service not known) ~~~ If this issue will be resolved, please add any useful information to the error message in addition to the host. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125733] [Ruby Bug#22110] Ruby::Box C-extension loading can be denied by predictable temporary filename
by hakuopi (haku opi) 13 Jun '26

13 Jun '26

Issue #22110 has been reported by hakuopi (haku opi). ---------------------------------------- Bug #22110: Ruby::Box C-extension loading can be denied by predictable temporary filename https://bugs.ruby-lang.org/issues/22110 * Author: hakuopi (haku opi) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-13 master 533abc7ded) [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby::Box is experimental, but I found a reproducible local hardening issue in its native extension loading path. When a C extension is required inside a Ruby::Box, Ruby copies the `.so` to a temporary filename derived from predictable values: ```text tmpdir + "_ruby_box_" + "p" + getpid() + "_" + box_id + "_" + escaped_basename ``` Because the filename has no random component, another same-host local user can pre-create the path before the victim process loads the extension. The victim’s `open(..., O_CREAT|O_EXCL, ...)` call then fails, and `require` raises `LoadError`. This does not allow code injection. `O_CREAT|O_EXCL` correctly rejects pre-existing files and symlinks. The impact is only denial of Ruby::Box C-extension loading. Environment: Ruby 4.1.0-dev @ 533abc7ded Ruby::Box enabled with `RUBY_BOX=1` Linux x86_64 Reproduction: From a Ruby build tree with `./ruby` available: ```sh RUBY=./ruby sh security_review_claude_opus48_max_20260613_050521/poc/box_dos_attack.sh ``` Observed: The attacker process discovers the victim PID, pre-creates likely paths under `/tmp`, and the victim fails with: ```text LoadError: can't prepare the extension file for Ruby Box (.../_ruby_box_p<pid>_4_fcntl.so from .../fcntl.so): can't open the file to write ``` Control: Without pre-creating the path, the same Ruby::Box extension require succeeds. Expected: A third-party same-host user should not be able to deny Ruby::Box C-extension loading by pre-creating a predictable temp filename. Suggested fix: Use an unpredictable temporary filename, for example `mkstemp` or a random suffix, preferably inside a private per-process directory with `0700` permissions. The copied extension file can also use mode `0600` instead of mirroring the source `.so` permissions. Notes: This is not a sandbox escape, not code execution, not privilege escalation, and not information disclosure. It is a local denial/hardening issue for an experimental opt-in feature. ---Files-------------------------------- box_dos_attack.sh (1.98 KB) box_poc_output.txt (1.11 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125692] [Ruby Bug#22103] Constant-folded /o regexp crashes with dupstring of a Regexp
by shugo (Shugo Maeda) 12 Jun '26

12 Jun '26

Issue #22103 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22103: Constant-folded /o regexp crashes with dupstring of a Regexp https://bugs.ruby-lang.org/issues/22103 * Author: shugo (Shugo Maeda) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A `/o` (once) regexp whose interpolation folds to a constant crashes at runtime: ```ruby def m; /#{"a"}/o; end m #=> [BUG] heap_idx_for_size: allocation size too large ``` A plain `/#{"a"}/` (no `/o`) is fine. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125718] [Ruby Feature#12639] Speed up require in RubyGems by 5x
by hsbt (Hiroshi SHIBATA) 12 Jun '26

12 Jun '26

Issue #12639 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed The performance gap this patch targeted has been mostly eliminated by incremental optimizations in RubyGems since 2016. Running the benchmark in the description on current master shows 1.47x (about 80ns per call) instead of 5x, because the require hook now returns early when there are no unresolved dependencies. Additionally, since RubyGems 3.5, Bundler disables the require decoration entirely after bundler/setup via Gem.discover_gems_on_require. The remaining overhead is too small to justify adding a new C API, so I'm closing this issue. ---------------------------------------- Feature #12639: Speed up require in RubyGems by 5x https://bugs.ruby-lang.org/issues/12639#change-117585 * Author: segiddins (Samuel Giddins) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- This patch makes requiring an already-loaded file approximated 5x faster when the RubyGems mixin for require is present. Benchmarked via the following script: ~~~ ruby require "rubygems" require "benchmark/ips" Benchmark.ips do |x| x.report("ruby") { gem_original_require "rubygems" } x.report("rubygems") { require "rubygems" } x.compare! end ~~~ I understand that it's not ideal to add new global functions, and I'd appreciate guidance on where else I could expose this functionality to ruby code. Thanks :) ---Files-------------------------------- feature_loaded.patch (1.85 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125717] [Ruby Feature#13508] How remove/refactor code related mathn library.
by hsbt (Hiroshi SHIBATA) 12 Jun '26

12 Jun '26

Issue #13508 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed All the items in this ticket have been resolved. The mathn-specific code in array.c, complex.c, rational.c and enum.c was removed at https://github.com/ruby/ruby/commit/b958e2add835d62c0a62edaf9a23ecbbd70a3635 (https://github.com/ruby/ruby/pull/3691) and the obsolete `--enable-mathn` configure option was removed at https://github.com/ruby/ruby/commit/89110b27437d4a84f7cb0387e59fd40d94efee1d. `lib/cmath.rb` was removed from the ruby repository at https://github.com/ruby/ruby/commit/a3b85016149f4f73f08c739626b2f02badd5ad17. The mathn workaround remaining in the cmath gem is intentionally kept for compatibility with the mathn gem. ---------------------------------------- Feature #13508: How remove/refactor code related mathn library. https://bugs.ruby-lang.org/issues/13508#change-117584 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I removed mathn library at r58413 and r58432. I have some concerns related mathn library. This issue is reminder for this concern. 1. Still remains conditions for mathn loaded. ex. https://github.com/ruby/ruby/blob/trunk/array.c#L5755 2. {complex,rational}.c have {nucomp,nurat}_canonicalization methods for mathn. 3. lib/cmath.rb have workaround code for mathn see. https://github.com/ruby/ruby/blob/trunk/lib/cmath.rb#L27 I continue to discuss concerns to @mrkn -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125716] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by koic (Koichi ITO) 12 Jun '26

12 Jun '26

Issue #18915 has been updated by koic (Koichi ITO). Thank you for taking the time to discuss this at the dev meeting. I realized that I had overlooked one issue. I found some existing code that defines `AbstractMethodError` with a superclass other than `ScriptError`. The impact on proprietary code is unknown, but a GitHub search shows the following results: https://github.com/search?q=%2Fclass+AbstractMethodError%2F+language%3ARuby… Not all of these define a top-level `AbstractMethodError`. For example, GitLab defines `Gitlab::AbstractMethodError` as a subclass of `Exception` within its own module namespace: https://gitlab.com/gitlab-org/gitlab/-/blob/v18.10.8-ee/lib/gitlab/abstract… However, for a top-level `AbstractMethodError`, a `TypeError` due to a superclass mismatch could occur depending on the superclass used by existing code. One possible path forward would be for applications and gems to migrate during Ruby 4.1-dev. That said, if such updates are not made, users may encounter compatibility issues. Given this, it seems worth considering whether to proceed with introducing the new class in Ruby 4.1. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117583 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0