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

[ruby-core:115035] [Ruby master Bug#19926] Range#size returns an incorrect result for ranges with a Rational endpoint
by kyanagi (Kouhei Yanagita) 13 Oct '23

13 Oct '23

Issue #19926 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19926: Range#size returns an incorrect result for ranges with a Rational endpoint https://bugs.ruby-lang.org/issues/19926 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12T17:32:45Z master 81399a5c46) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` % ~/tmp/ruby-master/bin/ruby -e '(1...3.1r).each { p _1 }' 1 2 3 ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (1...3.1r).size' 2 ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (1...3.1).size' 3 ``` -- https://bugs.ruby-lang.org/

1 1

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

13 Oct '23

Issue #18915 has been updated by byroot (Jean Boussier). > I wouldn't expect a test framework to rescue OutOfMemoryError for example, Well Minitest does rescue Exception: https://github.com/minitest/minitest/blob/6719ad8d8d49779669083f5029ea9a042… Pretty sure RSpec does as well. It's one of the rare justifiable cases for doing so. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104923 * 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:115048] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by tenderlovemaking (Aaron Patterson) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson). byroot (Jean Boussier) wrote in #note-10: > > since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class > > Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly. It is something I would like rescued broadly. For example if I'm test driving a concrete implementation, the test framework needs to specifically rescue `NotImplementedError` in order to report the error. I wouldn't expect a test framework to rescue OutOfMemoryError for example, but definitely rescue NotImplementedError. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104922 * 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:115046] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by byroot (Jean Boussier) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by byroot (Jean Boussier). > since NotImplementedError doesn't inherit from StandardError I kind of wish there was a new exception class Could you elaborate? For this use case I think not inheriting from `StandardError` is better, as it's not something you'd want to be rescued broadly. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104920 * 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:115045] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Quintasan 13 Oct '23

13 Oct '23

Issue #18915 has been updated by Quintasan (Michał Zając). tenderlovemaking (Aaron Patterson) wrote in #note-8: > I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. Hence my proposal to introduce a new class. I didn't want to create a PR for either solution because I would welcome both of them. I'm slightly leaning towards a new exception class for this. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104919 * 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:115043] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by tenderlovemaking (Aaron Patterson) 13 Oct '23

13 Oct '23

Issue #18915 has been updated by tenderlovemaking (Aaron Patterson). I'm guilty of using `NotImplementedError` for abstract classes. I like the idea of changing the documentation, but on the other hand, since `NotImplementedError` doesn't inherit from StandardError I kind of wish there was a new exception class. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-104917 * 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:114782] [Ruby master Bug#19885] Invalid Warning for Default Gems That Will Move to Bundled Gems
by jeremyevans0 (Jeremy Evans) 13 Oct '23

13 Oct '23

Issue #19885 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #19885: Invalid Warning for Default Gems That Will Move to Bundled Gems https://bugs.ruby-lang.org/issues/19885 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONTNEED ---------------------------------------- Starting in ruby 3.3.0-preview2, attempting to require bigdecimal, mutex_m, base64, or other libraries that will move to bundled gems in Ruby 3.4.0 results in a warning, even when bundler is not in use: ``` $ ruby33 -v -r bigdecimal -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` I think such warnings are bugs if bundler is not in use. When a library is moved from a default gem to a bundled gem, such code will work fine if not using bundler. It is only when using bundler where such code would have problems, and therefore, if Ruby warns at all, it should only warn when bundler is in use. The only time such a warning would make sense if bundler is not in use is if the library was not going to be a bundled gem. In that case, first the library should be moved from a default gem to a bundled gem, then the bundled gem that ships with Ruby should provide the warning, which you can avoid by installing an updated gem version. Note that you also get the warning when loading a gem that has bigdecimal as a runtime dependency (this example uses Sequel 5.72.0, which has a runtime dependency on bigdecimal as you can see at https://rubygems.org/gems/sequel/versions/5.72.0) ``` $ ruby33 -v -r sequel -e '' ruby 3.3.0preview2 (2023-09-14 master e50fcca9a7) [x86_64-openbsd] /usr/local/lib/ruby/gems/3.3/gems/sequel-5.72.0/lib/sequel/core.rb:3: warning: bigdecimal which will be not part of the default gems since Ruby 3.4.0 ``` This warning makes even less sense, because even if bigdecimal was removed as both a default gem and a bundled gem, installing Sequel 5.72.0 would install bigdecimal as a dependency. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:115020] [Ruby master Bug#19923] Ractor / YJIT failures on PPC64LE
by vo.x (Vit Ondruch) 13 Oct '23

13 Oct '23

Issue #19923 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19923: Ractor / YJIT failures on PPC64LE https://bugs.ruby-lang.org/issues/19923 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master e029375a7d) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Let me share snippet of the log: ~~~ ... snip ... + DISABLE_TESTS= + MSPECOPTS= + DISABLE_TESTS=' -n !/TestYJIT#test_bug_19316/' + make -C redhat-linux-build check 'TESTS=-v --show-skip -n !/TestYJIT#test_bug_19316/' 'MSPECOPT=-fs ' make: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' BASERUBY = echo executable host ruby is required. use --with-baseruby option.; false CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -fPIC -m64 XCFLAGS = -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/powerpc64le-linux -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/include -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/prism -I/builddir/build/BUILD/ruby-3.3.0-e029375a7d/enc/unicode/15.0.0 CPPFLAGS = DLDFLAGS = -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-soname,libruby.so.3.3 -fstack-protector-strong -m64 SOLIBS = -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lpthread LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = no YJIT_RUSTC_ARGS = --crate-name=yjit --crate-type=staticlib --edition=2021 -g -C lto=thin -C opt-level=3 -C overflow-checks=on '--out-dir=/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build/yjit/target/release/' /builddir/build/BUILD/ruby-3.3.0-e029375a7d/yjit/src/lib.rs gcc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. generating enc.mk making srcs under enc make[1]: Entering directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' ... snip ... make[1]: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' 2023-10-12 15:27:51 +0000 Driver is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] Target is ruby 3.3.0dev (2023-10-12 master e029375a7d) [powerpc64le-linux] test_attr.rb ... test_autoload.rb ........ test_block.rb .................................................... ...... test_class.rb ................................................ test_constant_cache.rb .......... test_env.rb .. test_eval.rb ........................................ test_exception.rb .................................. test_fiber.rb ..... test_finalizer.rb . test_flip.rb . test_flow.rb .................................................... .......... test_fork.rb .... test_gc.rb .. test_insns.rb .................................................... ............................................................................... ............................................................................... ............................................................................... ............................................................................... ................... test_io.rb .................. test_jump.rb ............................. test_literal.rb .................................................... ............................................................................... ......................... test_literal_suffix.rb ................................................ test_load.rb .. test_marshal.rb . test_massign.rb .................................. test_method.rb .................................................... ............................................................................... ............................................................................... ............. test_objectspace.rb ...... test_proc.rb ..................................... test_ractor.rb .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_7_1222.rb:2:in `<main>' .Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_30_1224.rb:2:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_ractor.rb_37_1225.rb:2:in `<main>' ... snip ... <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_391_1855.rb:3:in `<main>' Fstderr output is not empty <internal:ractor>:282:in `new': can't create Thread: Invalid argument (ThreadError) from bootstraptest.test_yjit_rust_port.rb_401_1856.rb:2:in `<main>' .. Finished in 57.56 sec Fiber count: 10000 (skipping) #1222 test_ractor.rb:7: Ractor.new{}.class #=> "" (expected "Ractor") #1224 test_ractor.rb:30: r = Ractor.new name: 'test-name' do end r.name #=> "" (expected "test-name") ... snip ... #1856 test_yjit_rust_port.rb:401: r = Ractor.new do msg = Ractor.receive end r.send 'ok' r.take #=> "" (expected "ok") FAIL 95/1857 tests failed make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-e029375a7d/redhat-linux-build' make: *** [uncommon.mk:886: yes-btest-ruby] Error 1 ~~~ The full log is in attachment. ---Files-------------------------------- build.log (1.01 MB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114399] [Ruby master Feature#19839] Need a method to check if two ranges overlap
by shouichi (Shouichi KAMIYA) 12 Oct '23

12 Oct '23

Issue #19839 has been reported by shouichi (Shouichi KAMIYA). ---------------------------------------- Feature #19839: Need a method to check if two ranges overlap https://bugs.ruby-lang.org/issues/19839 * Author: shouichi (Shouichi KAMIYA) * Status: Open * Priority: Normal ---------------------------------------- It would be convenient to have a method that checks if two ranges overlap. For example, ``` (0..10).overlap?(5..15) #=> true (0..10).overlap?(20..30) #=> false ``` -- https://bugs.ruby-lang.org/

12 26

[ruby-core:115031] [Ruby master Misc#18984] Doc for Range#size for Float/Rational does not make sense
by mame (Yusuke Endoh) 12 Oct '23

12 Oct '23

Issue #18984 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. @matz said that he wanted to try to fix the behavior of Range#size instead of changing the document. If the incompatibilty is found significant, it will be reconsidered. ```ruby (0.51..5.quo(2)).size #=> TypeError (..0).size #=> TypeError ``` ---------------------------------------- Misc #18984: Doc for Range#size for Float/Rational does not make sense https://bugs.ruby-lang.org/issues/18984#change-104902 * Author: masasakano (Masa Sakano) * Status: Open * Priority: Normal ---------------------------------------- When `Range` consists of any Numeric, according to [Official docs for Ruby-3.1.2](https://ruby-doc.org/core-3.1.2/Range.html#method-i-size), `Range#size` should, > Returns the count of elements in self if both begin and end values are numeric; Indeed, when `Range` consists of only `Integer`, this makes sense. However, when the begin value of `Range` is a `Float` or `Rational`, "*the count of elements*" does not make sense. Such Ranges are not iteratable, suggesting there are no such things as "elements": ```ruby (0.51..5.quo(2)).each{} # => TypeError ``` Yet, `Range#size` of such Ranges returns an Integer ```ruby (0.51..5.quo(2)).size # => 2 ``` It seems both begin and end values of a Range are rounded (`Numeric#round`) to the nearest Integer before `Range#size` is calculated. If this is the specification, I suggest it should be clearly stated in the [Official docs](https://ruby-doc.org/core-3.1.2/Range.html#method-i-size), avoiding the confusing expression "the count of elements", because "elements" are not unambiguously defined for Range of Float/Rational. -- https://bugs.ruby-lang.org/

1 0