December 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113951] [Ruby master Bug#19738] `ObjectSpace.each_object.to_a` crashes in `make runirb`.
by ioquatix (Samuel Williams) 26 Dec '23

26 Dec '23

Issue #19738 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19738: `ObjectSpace.each_object.to_a` crashes in `make runirb`. https://bugs.ruby-lang.org/issues/19738 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` > make runirb RUBY_ON_BUG='gdb -x ./.gdbinit -p' ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r irb -e 'IRB.start("make runirb")' irb(main):001:0> ObjectSpace.each_object.to_a Assertion Failed: ./vm_method.c:1366:callable_method_entry_or_negative:RB_TYPE_P(klass, T_CLASS) || RB_TYPE_P(klass, T_ICLASS) ruby 3.3.0dev (2023-06-19T19:19:45Z master 9ff4399dec) [arm64-darwin22] ``` I have no idea why. ---Files-------------------------------- error.txt (12.9 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115881] [Ruby master Bug#20082] Killing fibers across threads: unexpected exception
by zverok (Victor Shepelev) 26 Dec '23

26 Dec '23

Issue #20082 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20082: Killing fibers across threads: unexpected exception https://bugs.ruby-lang.org/issues/20082 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- For providing the example in a changelog, I tried to imitate killing fibers belonging to other threads. Documentation [claims](https://docs.ruby-lang.org/en/master/Fiber.html#method-i-kill) > Raises FiberError if called on a fiber belonging to another thread. So, I created this artificial example to check how it works: ```ruby fibers = [] Thread.new { f = Fiber.new { (1..).each { sleep(0.1) } } fibers << f f.resume } sleep(0.1) # to make sure the thread has started fibers.last.kill ``` The example indeed fails with `FiberError`, but the error message is confusing: ``` in `kill': attempt to resume a resumed fiber (double resume) (FiberError) ``` Is this an expected message for such case? Or am I misunderstanding something? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115884] Windows Ruby 3.2.2: Non-English character added to Windows Registry String Value
by Jay Mav 26 Dec '23

26 Dec '23

Hello, Compiled Ruby 3.2.2 on Windows with MSVC 2019 - Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30147 for x64. Code: require 'win32/registry' win_oracle_key = "SOFTWARE\\ORACLE" reg=Win32::Registry::HKEY_LOCAL_MACHINE.open(win_oracle_key, Win32::Registry::KEY_ALL_ACCESS) inst_loc_key = "inst_loc" inv_dir="C:\\Program Files\\Tester\\Inventory" reg[inst_loc_key] = inv_dir .... Registry contains: C:\Program Files\Tester\Inventory洀 (Not sure what that character represents.) Can the Ruby Dev Team please let me know how to resolve this issue so that this character does not get added to the string? Thanks in advance.

1 2

[ruby-core:114345] [Ruby master Bug#19831] warning message of linker with macOS Sonoma beta
by hsbt (Hiroshi SHIBATA) 26 Dec '23

26 Dec '23

Issue #19831 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19831: warning message of linker with macOS Sonoma beta https://bugs.ruby-lang.org/issues/19831 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Xcode 15 beta and macOS Sonoma beta show the following warnings with `make` ``` (snip) linking miniruby ld: warning: ignoring duplicate library '-lpthread' miniruby: replacing existing signature exe/ruby: replacing existing signature builtin_binary.inc updated compiling builtin.c linking static-library libruby.3.3-static.a linking ruby ld: warning: ignoring duplicate library '-lgmp' ld: warning: ignoring duplicate library '-ldl' ld: warning: ignoring duplicate library '-lobjc' ld: warning: ignoring duplicate library '-lpthread' ld: warning: ignoring duplicate library '-lpthread' (snip) ``` I'm not investigate that yet. It may be caused by `ld-prime` that is new linker of macOS platform. ``` $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 15.0.0.0.1.1690355577 volume: / location: / install-time: 1690967267 ``` -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115887] Ruby 3.3.0 Released
by NARUSE, Yui 25 Dec '23

25 Dec '23

We are pleased to announce the release of Ruby 3.3.0. Ruby 3.3 adds a new parser named Prism, uses Lrama as a parser generator, adds a new pure-Ruby JIT compiler named RJIT, and many performance improvements especially YJIT. ## Prism * Introduced [the Prism parser](https://github.com/ruby/prism) as a default gem * Prism is a portable, error tolerant, and maintainable recursive descent parser for the Ruby language * Prism is production ready and actively maintained, you can use it in place of Ripper * There is [extensive documentation](https://ruby.github.io/prism/) on how to use Prism * Prism is both a C library that will be used internally by CRuby and a Ruby gem that can be used by any tooling which needs to parse Ruby code * Notable methods in the Prism API are: * `Prism.parse(source)` which returns the AST as part of a parse result object * `Prism.parse_comments(source)` which returns the comments * `Prism.parse_success?(source)` which returns true if there are no errors * You can make pull requests or issues directly on [the Prism repository](https://github.com/ruby/prism) if you are interested in contributing * You can now use `ruby --parser=prism` or `RUBYOPT="--parser=prism"` to experiment with the Prism compiler. Please note that this flag is for debugging only. ## Use Lrama instead of Bison * Replace Bison with [Lrama LALR parser generator](https://github.com/ruby/lrama) [[Feature #19637]](https://bugs.ruby-lang.org/issues/19637) * If you have interest, please see [The future vision of Ruby Parser](https://rubykaigi.org/2023/presentations/spikeolaf.html) * Lrama internal parser is replaced with LR parser generated by Racc for maintainability * Parameterizing Rules `(?, *, +)` are supported, it will be used in Ruby parse.y ## YJIT * Major performance improvements over Ruby 3.2 * Support for splat and rest arguments has been improved. * Registers are allocated for stack operations of the virtual machine. * More calls with optional arguments are compiled. Exception handlers are also compiled. * Unsupported call types and megamorphic call sites no longer exit to the interpreter. * Basic methods like Rails `#blank?` and [specialized `#present?`](https://github.com/rails/rails/pull/49909) are inlined. * `Integer#*`, `Integer#!=`, `String#!=`, `String#getbyte`, `Kernel#block_given?`, `Kernel#is_a?`, `Kernel#instance_of?`, and `Module#===` are specially optimized. * Compilation speed is now slightly faster than Ruby 3.2. * Now more than 3x faster than the interpreter on Optcarrot! * Significantly improved memory usage over Ruby 3.2 * Metadata for compiled code uses a lot less memory. * `--yjit-call-threshold` is automatically raised from 30 to 120 when the application has more than 40,000 ISEQs. * `--yjit-cold-threshold` is added to skip compiling cold ISEQs. * More compact code is generated on Arm64. * Code GC is now disabled by default * `--yjit-exec-mem-size` is treated as a hard limit where compilation of new code stops. * No sudden drops in performance due to code GC. Better copy-on-write behavior on servers reforking with [Pitchfork](https://github.com/shopify/pitchfork). * You can still enable code GC if desired with `--yjit-code-gc` * Add `RubyVM::YJIT.enable` that can enable YJIT at run-time * You can start YJIT without modifying command-line arguments or environment variables. Rails 7.2 will [enable YJIT by default](https://github.com/rails/rails/pull/49947) using this method. * This can also be used to enable YJIT only once your application is done booting. `--yjit-disable` can be used if you want to use other YJIT options while disabling YJIT at boot. * More YJIT stats are available by default * `yjit_alloc_size` and several more metadata-related stats are now available by default. * `ratio_in_yjit` stat produced by `--yjit-stats` is now available in release builds, a special stats or dev build is no longer required to access most stats. * Add more profiling capabilities * `--yjit-perf` is added to facilitate profiling with Linux perf. * `--yjit-trace-exits` now supports sampling with `--yjit-trace-exits-sample-rate=N` * More thorough testing and multiple bug fixes ## RJIT * Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT. * RJIT supports only x86-64 architecture on Unix platforms. * Unlike MJIT, it doesn't require a C compiler at runtime. * RJIT exists only for experimental purposes. * You should keep using YJIT in production. * If you are interested in developing JIT for Ruby, please check out [k0kubun's presentation on Day 3 of RubyKaigi](https://rubykaigi.org/2023/presentations/k0kubun.html#day3). ## M:N thread scheduler * M:N thread scheduler was introduced. [[Feature #19842]](https://bugs.ruby-lang.org/issues/19842) * M Ruby threads are managed by N native threads (OS threads) so the thread creation and management cost are reduced. * It can break C-extension compatibility so that M:N thread scheduler is disabled on the main Ractor by default. * `RUBY_MN_THREADS=1` environment variable enables M:N threads on the main Ractor. * M:N threads are always enabled on non-main Ractors. * `RUBY_MAX_CPU=n` environment variable sets maximum number of `N` (maximum number of native threads). The default value is 8. * Since only one Ruby thread per Ractor can run at the same time, the number of native threads will be used, which is the smaller of the number specified in `RUBY_MAX_CPU` and the number of running Ractors. So that single Ractor applications (most of applications) will only use 1 native thread. * To support blocking operations, more than `N` native threads can be used. ## Performance improvements * `defined?(@ivar)` is optimized with Object Shapes. * Name resolution such as `Socket.getaddrinfo` can now be interrupted (in environments where pthreads are available). [[Feature #19965]](https://bugs.ruby-lang.org/issues/19965) * Several performance improvements to the Garbage Collector * Young objects referenced by old objects are no longer immediately promoted to the old generation. This significantly reduces the frequency of major GC collections. [[Feature #19678]](https://bugs.ruby-lang.org/issues/19678) * A new `REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO` tuning variable was introduced to control the number of unprotected objects cause a major GC collection to trigger. The default is set to `0.01` (1%). This significantly reduces the frequency of major GC collection. [[Feature #19571]](https://bugs.ruby-lang.org/issues/19571) * Write Barriers were implemented for many core types that were missing them, notably `Time`, `Enumerator`, `MatchData`, `Method`, `File::Stat`, `BigDecimal` and several others. This significantly reduces minor GC collection time and major GC collection frequency. * Most core classes are now using Variable Width Allocation, notably `Hash`, `Time`, `Thread::Backtrace`, `Thread::Backtrace::Location`, `File::Stat`, `Method`. This makes these classes faster to allocate and free, use less memory and reduce heap fragmentation. * Support for weak references has been added to the garbage collector. [[Feature #19783]](https://bugs.ruby-lang.org/issues/19783) ## Other notable changes since 3.2 ### IRB IRB has received several enhancements, including but not limited to: - Advanced `irb:rdbg` integration that provides an equivalent debugging experience to `pry-byebug` ([doc](https://github.com/ruby/irb#debugging-with-irb)) - Pager support for `ls`, `show_source` and `show_cmds` commands. - More accurate and helpful information provided by the `ls` and `show_source` commands. - Experimental autocompletion using type analysis ([doc](https://github.com/ruby/irb#type-based-completion)) - It is now possible to change the font color and font style in the completion dialog by a newly introduced class Reline::Face ([doc](https://github.com/ruby/ruby/blob/master/doc/reline/face.md)) In addition, IRB has also undergone extensive refactoring and received dozens of bug fixes to facilitate easier future enhancements. ## Compatibility issues Note: Excluding feature bug fixes. * `it` calls without arguments in a block with no ordinary parameters are deprecated. `it` will be a reference to the first block parameter in Ruby 3.4. [[Feature #18980]](https://bugs.ruby-lang.org/issues/18980) ### Removed environment variables The following deprecated methods are removed. * Environment variable `RUBY_GC_HEAP_INIT_SLOTS` has been deprecated and is a no-op. Please use environment variables `RUBY_GC_HEAP_{0,1,2,3,4}_INIT_SLOTS` instead. [[Feature #19785]](https://bugs.ruby-lang.org/issues/19785) ## Stdlib compatibility issues ### `ext/readline` is retired * We have `reline` that is pure Ruby implementation compatible with `ext/readline` API. We rely on `reline` in the future. If you need to use `ext/readline`, you can install `ext/readline` via rubygems.org with `gem install readline-ext`. * We no longer need to install libraries like `libreadline` or `libedit`. ## Standard library updates RubyGems and Bundler warn if users do `require` the following gems without adding them to Gemfile or gemspec. This is because they will become the bundled gems in the future version of Ruby. This warning is suppressed if you use bootsnap gem. We recoomend to run your application with `DISABLE_BOOTSNAP=1` environmental variable at least once. This is limitation of this version. Targeted libraries are: * abbrev * base64 * bigdecimal * csv * drb * getoptlong * mutex_m * nkf * observer * racc * resolv-replace * rinda * syslog The following default gem is added. * prism 0.19.0 The following default gems are updated. * RubyGems 3.5.3 * abbrev 0.1.2 * base64 0.2.0 * benchmark 0.3.0 * bigdecimal 3.1.5 * bundler 2.5.3 * cgi 0.4.1 * csv 3.2.8 * date 3.3.4 * delegate 0.3.1 * drb 2.2.0 * english 0.8.0 * erb 4.0.3 * error_highlight 0.6.0 * etc 1.4.3 * fcntl 1.1.0 * fiddle 1.1.2 * fileutils 1.7.2 * find 0.2.0 * getoptlong 0.2.1 * io-console 0.7.1 * io-nonblock 0.3.0 * io-wait 0.3.1 * ipaddr 1.2.6 * irb 1.11.0 * json 2.7.1 * logger 1.6.0 * mutex_m 0.2.0 * net-http 0.4.0 * net-protocol 0.2.2 * nkf 0.1.3 * observer 0.1.2 * open-uri 0.4.1 * open3 0.2.1 * openssl 3.2.0 * optparse 0.4.0 * ostruct 0.6.0 * pathname 0.3.0 * pp 0.5.0 * prettyprint 0.2.0 * pstore 0.1.3 * psych 5.1.2 * rdoc 6.6.2 * readline 0.0.4 * reline 0.4.1 * resolv 0.3.0 * rinda 0.2.0 * securerandom 0.3.1 * set 1.1.0 * shellwords 0.2.0 * singleton 0.2.0 * stringio 3.1.0 * strscan 3.0.7 * syntax_suggest 2.0.0 * syslog 0.1.2 * tempfile 0.2.1 * time 0.3.0 * timeout 0.4.1 * tmpdir 0.2.0 * tsort 0.2.0 * un 0.3.0 * uri 0.13.0 * weakref 0.1.3 * win32ole 1.8.10 * yaml 0.3.0 * zlib 3.1.0 The following bundled gem is promoted from default gems. * racc 1.7.3 The following bundled gems are updated. * minitest 5.20.0 * rake 13.1.0 * test-unit 3.6.1 * rexml 3.2.6 * rss 0.3.0 * net-ftp 0.3.3 * net-imap 0.4.9 * net-smtp 0.4.0 * rbs 3.4.0 * typeprof 0.21.9 * debug 1.9.1 See GitHub releases like [Logger](https://github.com/ruby/logger/releases) or changelog for details of the default gems or bundled gems. See [NEWS](https://github.com/ruby/ruby/blob/v3_3_0/NEWS.md) or [commit logs](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0) for more details. With those changes, [5532 files changed, 326851 insertions(+), 185793 deletions(-)](https://github.com/ruby/ruby/compare/v3_2_0...v3_3_0#file_buc… since Ruby 3.2.0! Merry Christmas, Happy Holidays, and enjoy programming with Ruby 3.3! ## Download * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.gz> SIZE: 22065999 SHA1: 1a7e56851bf29bda1183aca99b3b323c58e0187b SHA256: 96518814d9832bece92a85415a819d4893b307db5921ae1f0f751a9a89a56b7d SHA512: 26074009b501fc793d71a74e419f34a6033c9353433919ca74ba2d24a3de432dbb11fd92c2bc285f0e4d951a6d6c74bf5b69a2ab36200c8c26e871746d6e0fc6 * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.tar.xz> SIZE: 16345456 SHA1: c8f68e1b0a114b90460a0b44165a3b2f540fa5b6 SHA256: 676b65a36e637e90f982b57b059189b3276b9045034dcd186a7e9078847b975b SHA512: 7959c5753bfa0bfc4d6d74060869aabbe9815c1c97930659da11b917ee0803ddbbd80e869e00c48b8694b4ba48709c3b6493fd045568e36e902616c35ababf01 * <https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0.zip> SIZE: 26935108 SHA1: a433eef1d7f96daeaf3b4cb842d0ed2dd82e7dc1 SHA256: 0e6563f679dd3694732eb3addf9de681c67b584602ac574376b60e7a509d2cd8 SHA512: a94a85937a14b217c1f4b90d24185289ed4aee79239c4f3eecf8034d3fd34e65ee8d66869473857ed153067188adc9b70c0471e4ebe842c9f98ef60c34090450 ## What is Ruby Ruby was first developed by Matz (Yukihiro Matsumoto) in 1993, and is now developed as Open Source. It runs on multiple platforms and is used all over the world especially for web development.

1 0

[ruby-core:111739] [Ruby master Feature#19324] Enumerator.product => Enumerable#product
by zverok (Victor Shepelev) 23 Dec '23

23 Dec '23

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/

6 17

[ruby-core:111988] [Ruby master Feature#19370] Anonymous parameters for blocks?
by zverok (Victor Shepelev) 23 Dec '23

23 Dec '23

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/

5 9

[ruby-core:115525] [Ruby master Feature#20027] Range Deconstruction
by stuyam (Stuart Yamartino) 22 Dec '23

22 Dec '23

Issue #20027 has been reported by stuyam (Stuart Yamartino). ---------------------------------------- Feature #20027: Range Deconstruction https://bugs.ruby-lang.org/issues/20027 * Author: stuyam (Stuart Yamartino) * Status: Open * Priority: Normal ---------------------------------------- Ranges are a powerful tool in ruby. A common range I use is a date range such as `(Date.yesterday..Date.tomorrow)`. A range will often be passed around to methods because the dates hold meaning together such as a timeframe for a table filter. Often I want to grab the original values out of a range like: ```ruby timeframe = (Date.yesterday..Date.tomorrow) start_date = timeframe.begin end_date = timeframe.end #=> start_date = yesterday #=> end_date = today ``` Similar to array and hash deconstruction I thought it would be useful to support range deconstruction like this: ```ruby start_date, end_date = (Date.yesterday..Date.tomorrow) #=> start_date = yesterday #=> end_date = today ``` This would also work for endless or beginless ranges since the beginning and end are just nil in those cases: ```ruby start_date, end_day = ..Date.tomorrow #=> start_date = nil #=> end_date = tomorrow ``` You could do this now using `to_a` like: ```ruby start_date, *middle_dates, end_date = (Date.new(2000,1,1)..Date.new(2023,1,1).to_a ``` However this has unnecessary performance issues by converting the range to an array especially if the range spans a large period, `middle_dates` would hold a very large array. Also if the range resulted in an array with 2 values, `end_date` would be nil and this wouldn't actually work to get the begin and end values. I think this provides a simple interface for a common pattern of deconstructing ranges into their beginning and end values. It would be useful for ranges regardless of date ranges or other types of ranges since they are essentially tuples. Would love to know what others think about this <3 -- https://bugs.ruby-lang.org/

4 7

[ruby-core:115862] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by byroot (Jean Boussier) 22 Dec '23

22 Dec '23

Issue #18915 has been updated by byroot (Jean Boussier). > How about raise NoMethodError Agreed. If people want an exception that inherits from `StandardError`, then `NoMethodError` perfectly fits the bill. I still think that "you forgot to implement this abstract method" shouldn't inherit from `StandardError` though, as it risk getting handled by the application and not surface during testing, hence why `NotImplementedError` already works great for that use case regardless of what the documentation says. Amusingly Python has the same error class for that purpose exactly: https://docs.python.org/3/library/exceptions.html#NotImplementedError > exception NotImplementedError > This exception is derived from RuntimeError. In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method, or while the class is being developed to indicate that the real implementation still needs to be added. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105820 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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

[ruby-core:115861] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Dan0042 (Daniel DeLorme) 22 Dec '23

22 Dec '23

Issue #18915 has been updated by Dan0042 (Daniel DeLorme). How about `raise NoMethodError, "method '#{__method__}' is not implemented in #{self.class}"` ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105819 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # 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