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

[ruby-core:119159] [Ruby master Bug#20733] Build failure with FreeBSD 13.3
by hsbt (Hiroshi SHIBATA) 08 Oct '24

08 Oct '24

Issue #20733 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20733: Build failure with FreeBSD 13.3 https://bugs.ruby-lang.org/issues/20733 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- FreeBSD 13.3 build on Ruby CI was failure from 1 week ago. I manually build ruby master on FreeBSD 13 and got the following error. ``` [hsbt@freebsd /usr/home/hsbt/ruby]$ make BASERUBY = /usr/local/bin/ruby --disable=gems CC = clang LD = ld LDSHARED = clang -shared CFLAGS = -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fdeclspec -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wextra-tokens -Wdeprecated-declarations -Wdivision-by-zero -Wdiv-by-zero -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wshorten-64-to-32 -Wwrite-strings -Wold-style-definition -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wunused-variable -Wmisleading-indentation -Wundef XCFLAGS = -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/amd64-freebsd13.3 -I./include -I. -I./prism -I./enc/unicode/15.0.0 -I/usr/local/include CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,-soname,showflags -fstack-protector-strong -pie SOLIBS = -lunwind -lexecinfo -lprocstat -lz -lrt -lrt -lgmp -ldl -lcrypt -lm -lthr LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = RUSTC = rustc 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=/usr/home/hsbt/ruby/yjit/target/release/' ./yjit/src/lib.rs FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367) Target: x86_64-unknown-freebsd13.3 Thread model: posix InstalledDir: /usr/bin generating encdb.h encdb.h unchanged generating enc.mk making srcs under enc generating transdb.h transdb.h unchanged generating makefiles ext/configure-ext.mk ext/configure-ext.mk unchanged installing default coverage libraries installing default date_core libraries installing digest libraries installing default digest libraries installing default sha2 libraries installing default console libraries installing default libraries installing default monitor libraries installing default objspace libraries compiling ossl_digest.c ossl_digest.c:66:14: warning: call to undeclared function 'EVP_MD_CTX_get0_md'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 66 | md = EVP_MD_CTX_get0_md(ctx); | ^ ossl_digest.c:66:12: error: incompatible integer to pointer conversion assigning to 'const EVP_MD *' (aka 'const struct evp_md_st *') from 'int' [-Wint-conversion] 66 | md = EVP_MD_CTX_get0_md(ctx); | ^ ~~~~~~~~~~~~~~~~~~~~~~~ ossl_digest.c:206:32: warning: call to undeclared function 'EVP_MD_CTX_get0_md'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 206 | if (EVP_DigestInit_ex(ctx, EVP_MD_CTX_get0_md(ctx), NULL) != 1) { | ^ ossl_digest.c:206:32: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const EVP_MD *' (aka 'const struct evp_md_st *') [-Wint-conversion] 206 | if (EVP_DigestInit_ex(ctx, EVP_MD_CTX_get0_md(ctx), NULL) != 1) { | ^~~~~~~~~~~~~~~~~~~~~~~ /usr/include/openssl/evp.h:550:61: note: passing argument to parameter 'type' here 550 | __owur int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, | ^ ossl_digest.c:290:40: warning: call to undeclared function 'EVP_MD_CTX_get0_md'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 290 | return rb_str_new_cstr(EVP_MD_name(EVP_MD_CTX_get0_md(ctx))); | ^ ossl_digest.c:290:40: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const EVP_MD *' (aka 'const struct evp_md_st *') [-Wint-conversion] 290 | return rb_str_new_cstr(EVP_MD_name(EVP_MD_CTX_get0_md(ctx))); | ^~~~~~~~~~~~~~~~~~~~~~~ /usr/include/openssl/evp.h:447:64: note: expanded from macro 'EVP_MD_name' 447 | # define EVP_MD_name(e) OBJ_nid2sn(EVP_MD_nid(e)) | ^ /usr/include/openssl/evp.h:446:54: note: expanded from macro 'EVP_MD_nid' 446 | # define EVP_MD_nid(e) EVP_MD_type(e) | ^ ../.././include/ruby/internal/intern/string.h:1515:25: note: expanded from macro 'rb_str_new_cstr' 1515 | ((RBIMPL_CONSTANT_P(str) ? \ | ^~~ ../.././include/ruby/internal/constant_p.h:33:55: note: expanded from macro 'RBIMPL_CONSTANT_P' 33 | # define RBIMPL_CONSTANT_P(expr) __builtin_constant_p(expr) | ^~~~ /usr/include/openssl/evp.h:445:31: note: passing argument to parameter 'md' here 445 | int EVP_MD_type(const EVP_MD *md); | ^ ossl_digest.c:290:40: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const EVP_MD *' (aka 'const struct evp_md_st *') [-Wint-conversion] 290 | return rb_str_new_cstr(EVP_MD_name(EVP_MD_CTX_get0_md(ctx))); | ^~~~~~~~~~~~~~~~~~~~~~~ /usr/include/openssl/evp.h:447:64: note: expanded from macro 'EVP_MD_name' 447 | # define EVP_MD_name(e) OBJ_nid2sn(EVP_MD_nid(e)) | ^ /usr/include/openssl/evp.h:446:54: note: expanded from macro 'EVP_MD_nid' 446 | # define EVP_MD_nid(e) EVP_MD_type(e) | ^ ../.././include/ruby/internal/intern/string.h:1517:25: note: expanded from macro 'rb_str_new_cstr' 1517 | rb_str_new_cstr) (str)) | ^~~ /usr/include/openssl/evp.h:445:31: note: passing argument to parameter 'md' here 445 | int EVP_MD_type(const EVP_MD *md); | ^ 3 warnings and 4 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/home/hsbt/ruby/ext/openssl *** Error code 1 Stop. make[1]: stopped in /usr/home/hsbt/ruby *** Error code 1 Stop. make: stopped in /usr/home/hsbt/ruby ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:119390] [Ruby master Feature#20775] Gemify win32-registry, win32-sspi and win32-resolv
by larskanis (Lars Kanis) 08 Oct '24

08 Oct '24

Issue #20775 has been reported by larskanis (Lars Kanis). ---------------------------------------- Feature #20775: Gemify win32-registry, win32-sspi and win32-resolv https://bugs.ruby-lang.org/issues/20775 * Author: larskanis (Lars Kanis) * Status: Open ---------------------------------------- Many libraries bundled with ruby have been gemified and were separated into it's own repository. Not so far the 3 win32 libraries: https://github.com/ruby/ruby/tree/master/ext/win32/lib/win32 * win32/registry * win32/resolv * win32/sspi win32-registry ----------- I started with win32/registry in https://github.com/larskanis/win32-registry * separate all commit into it's own repository, * make it a gem, * add proper test cases to verify the core functions, * add a GHA workflow to run the tests, * add a single commit to change to consistent UTF-8 string output (see https://bugs.ruby-lang.org/issues/20774) My intention is that the repository can be moved to https://github.com/ruby/win32-registry and can be integrated it into ruby. However I think `win32/registry` should permanently stay a bundled gem, since the registry access is a core functionality on Windows, so it should always be in the core ruby distribution. win32-sspi ----------- Regarding `win32/sspi` I doubt that anyone is using this library. It was completely broken since ruby-3.0 until some days ago due to this fix: https://github.com/ruby/ruby/commit/fc2f196cb8542a81bf271cdb90e0189c54321103 Nevertheless it makes sense to gemify it and to move it to it's own repository. I use a massively extended version of this file at work, maybe this can be included then. IMHO there's no need to keep it in the ruby distribution. win32-resolv --------- I don't have a strong opinion reg. `win32/resolv` and never had a reason to use this platform dependent API instead of the cross platform functions in the `socket` library. Maybe it had a use in the past. -- https://bugs.ruby-lang.org/

3 11

[ruby-core:119444] [Ruby master Bug#20783] --enable-shared and the rpath/runpath are broken on Linux on CRuby master
by Eregon (Benoit Daloze) 08 Oct '24

08 Oct '24

Issue #20783 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #20783: --enable-shared and the rpath/runpath are broken on Linux on CRuby master https://bugs.ruby-lang.org/issues/20783 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- https://github.com/ruby/ruby-dev-builder/actions/runs/11095200420 ``` $ ruby test_files/cli_test.rb ruby: error while loading shared libraries: libruby.so.3.4: cannot open shared object file: No such file or directory ``` And indeed locally I can confirm it's broken (I use ruby-build for convenience, as you can see it just does a bunch of regular build commands): ``` $ RUBY_CONFIGURE_OPTS=--enable-shared ruby-build ruby-dev -d ~/.rubies ==> Cloning https://github.com/ruby/ruby.git... -> git clone --depth 1 --branch master https://github.com/ruby/ruby.git ruby-master ... ==> Installing ruby-master... -> autoreconf -i -> ./configure "--prefix=$HOME/.rubies/ruby-dev" --enable-shared -> make -j 16 -> make update-gems extract-gems install ==> Installed ruby-master to /home/eregon/.rubies/ruby-dev ``` And that build with `--enable-shared` is not working, same as on GitHub Actions: ``` $ ldd /home/eregon/.rubies/ruby-dev/bin/ruby linux-vdso.so.1 (0x00007fff9018c000) libruby.so.3.4 => not found libz.so.1 => /lib64/libz.so.1 (0x00007f4c8d928000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f4c8d8ef000) libm.so.6 => /lib64/libm.so.6 (0x00007f4c8d80e000) libc.so.6 => /lib64/libc.so.6 (0x00007f4c8d62c000) /lib64/ld-linux-x86-64.so.2 (0x00007f4c8d95e000) $ readelf -d /home/eregon/.rubies/ruby-dev/bin/ruby Dynamic section at offset 0x2db8 contains 29 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libruby.so.3.4] 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/home/eregon/.rubies/ruby-dev/lib-L/home/eregon/.rubies/ruby-dev/lib] ... ``` @hsbt said he remembers https://github.com/ruby/ruby/commit/1f6d2e77d9be9a5a829e60908d21d621f4e1ceb0 changed something in this area which might be the cause. Once this is fixed we should also revert https://github.com/ruby/docker-images/pull/107. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118979] [Ruby master Feature#20705] Should "0.E-9" be a valid float value?
by kou (Kouhei Sutou) 08 Oct '24

08 Oct '24

Issue #20705 has been reported by kou (Kouhei Sutou). ---------------------------------------- Feature #20705: Should "0.E-9" be a valid float value? https://bugs.ruby-lang.org/issues/20705 * Author: kou (Kouhei Sutou) * Status: Open ---------------------------------------- Ruby doesn't accept "0.E-9" as a valid float value: ```console $ ruby -e 'Float("0.E-9")' <internal:kernel>:218:in 'Kernel#Float': invalid value for Float(): "0.E-9" (ArgumentError) from -e:1:in '<main>' ``` But other systems accept "0.E-9" as a valid float value: PostgreSQL: ```text => select 0.E-9; ?column? ------------- 0.000000000 (1 row) ``` MySQL: ```text > select 0.E-9; +-------+ | 0.E-9 | +-------+ | 0 | +-------+ 1 row in set (0.00 sec) ``` Python: ```console $ python3 -c 'print(0.E-9)' 0.0 ``` Node.js: ```console $ nodejs -e 'console.log(0.E-9)' 0 ``` Should Ruby accept "0.E-9" as a valid float value? FYI: I don't have an opinion of this. I just realized this by an issue from an user of a maintained library by me: https://github.com/apache/arrow/issues/43877 -- https://bugs.ruby-lang.org/

6 10

[ruby-core:119212] [Ruby master Misc#20746] Request to migrate the json gem from flori/json repository to ruby/json
by byroot (Jean Boussier) 08 Oct '24

08 Oct '24

Issue #20746 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #20746: Request to migrate the json gem from flori/json repository to ruby/json https://bugs.ruby-lang.org/issues/20746 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context The `json` gem, which is part of Ruby's default gems, is the only default gem (aside from `rubygems` itself) for which the source repository isn't under the `ruby/` organization. @naruse and @hsbt, the two maintainers have merge permission into the repository, and gem ownership on, but no administrative right. The sole repository administrator is @flori, but he has been inactive for years. ### Problem - This prevent the maintainers to change the repository configuration to change CI and other integrations. - This prevent the maintainers from giving commit bit to others, e.g. JRuby/TruffleRuby maintainers. @hsbt has been trying to contact @flori for over two years now (first email in June 2022) and never got any answer. Later on we tried to contact him via GitHub where he seems active: https://github.com/flori/json/issues/591, but without success. I even asked him to please respond after he merged one of my contribution to one of his projects, but he ignored that too: https://github.com/flori/term-ansicolor/pull/38#issuecomment-2263838711 ### Proposal To resolve this situation I propose the following: - Create a copy of the repository at `ruby/json`. - Update the `json.gemspec` to declare `ruby/json` as the gem official repository. - Resume development there. NB: This is not taking anything away from @flori, if he wishes to remain administrator of the repository, we can perfectly add him as administrator of `ruby/json`. cc @Eregon -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119476] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Eregon (Benoit Daloze) 07 Oct '24

07 Oct '24

Issue #6648 has been updated by Eregon (Benoit Daloze). @nobu True, it would also be helpful to have a way to capture the original CWD. Then that example would work just fine with `ruby -C subdir -e 'exec(RbConfig.ruby, *Process.ruby_args, "-e", "p :OK", chdir: Process.original_working_directory)'` (using the naming from https://bugs.ruby-lang.org/issues/6648#note-10 but with `Process`). @byroot 's PR shows it's quite easy to get this information (although that's for all args, not just ruby command line/vm args, but that should be easy to fix): https://github.com/ruby/ruby/pull/11370 ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-110093 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119145] [Ruby master Misc#20728] Propose Eileen Uchitelle as a core committer
by kddnewton (Kevin Newton) 07 Oct '24

07 Oct '24

Issue #20728 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20728: Propose Eileen Uchitelle as a core committer https://bugs.ruby-lang.org/issues/20728 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I'd like to propose Eileen Uchitelle (@eileencodes) as a core committer. Now that Prism ([Feature #20564]) is merged, I would like her help maintaining the Prism parser and compiler without having to go through me to get patches merged. Besides being very helpful on Prism development and maintenance, Eileen has also contributed in myriad ways over the last 4 years, including: * Warning.warn categories (https://github.com/ruby/ruby/pull/3418) * Inline caches for class variables (https://bugs.ruby-lang.org/issues/17763) * Implementing instructions for YJIT (https://github.com/ruby/ruby/commit/2ba090a1f9258035b40374f9ff9da3ff920701cd) * Tracing exits for YJIT (https://github.com/ruby/ruby/pull/5970) * Helping out on the GC rectoring work (https://github.com/ruby/ruby/pull/10358) Overall I think she would be a great addition (and would help me a lot!). -- https://bugs.ruby-lang.org/

11 13

[ruby-core:117564] [Ruby master Bug#20433] Hash.inspect for some hash returns syntax invalid representation
by tompng (tomoya ishida) 05 Oct '24

05 Oct '24

Issue #20433 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20433: Hash.inspect for some hash returns syntax invalid representation https://bugs.ruby-lang.org/issues/20433 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- For these hashes, Hash.inspect returns a syntax invalid representation: ~~~ruby { :a! => 1 } # {:a!=>1} { :a? => 1 } # {:a?=>1} { :* => 1 } # {:*=>1} { :== => 1 } # {:===>1} { :< => 1 } # {:<=>1} ~~~ `eval(hash.inspect)` will raise SyntaxError. Although inspect does not guarantee that the result can be eval-ed, it'd be confusing for these few cases. Maybe related to https://bugs.ruby-lang.org/issues/20235 -- https://bugs.ruby-lang.org/

10 15

[ruby-core:119460] [Ruby master Bug#20784] `?\` followed by EOF is parsed wrong
by tompng (tomoya ishida) 05 Oct '24

05 Oct '24

Issue #20784 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20784: `?\` followed by EOF is parsed wrong https://bugs.ruby-lang.org/issues/20784 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby -v: ruby 3.4.0dev (2024-10-05T02:36:21Z master e939f28cc9) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `?\` at EOF should be syntax error ~~~ % printf "p ?\\" | ruby --parser=parse.y [nothing shown] % printf "1 in a ?\\" | ruby --parser=parse.y -c Syntax OK ~~~ With `--parser=prism`, `?\` at EOF is parsed as empty string, reported in https://github.com/ruby/prism/issues/3144 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119459] [Ruby master Feature#17326] Add Kernel#must! to the standard library
by matz (Yukihiro Matsumoto) 05 Oct '24

05 Oct '24

Issue #17326 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed I still do not see the need for this method. Although this method can be used for type assertion, there are no plans at this time to introduce features related to type declarations and assertion into the language core. Matz. ---------------------------------------- Feature #17326: Add Kernel#must! to the standard library https://bugs.ruby-lang.org/issues/17326#change-110079 * Author: jez (Jake Zimmerman) * Status: Closed ---------------------------------------- # Abstract We should add a method `Kernel#must!` (name TBD) which raises if `self` is `nil` and returns `self` otherwise. # Background Ruby 3 introduces type annotations for the standard library. Type checkers consume these annotations, and report errors for type mismatches. One of the most common and most valuable type errors is whether `nil` is allowed as an argument or return value. Sorbet's type system tracks this, and RBS files have syntax for annotating whether `nil` is allowed or not. Since Sorbet checks proper usage of `nil`, it requires code that looks like this: ```ruby if thing.nil? raise "The thing was nil" end thing.do_something ``` This is good because it forces the programmer to acknowledge that the thing might be `nil`, and declare that they'd rather raise an exception in that case than handle the `nil` (of course, there are many other times where `nil` is both possible and valid, which is why Sorbet forces at least considering in all cases). It is annoying and repetitive to have to write these `if .nil?` checks everywhere to ignore the type error, so Sorbet provides it as a library function, called `T.must`: ```ruby T.must(thing).do_something ``` Sorbet knows that the call to `T.must` raises if `thing` is `nil`. To make this very concrete, here's a Sorbet playground where you can see this in action: [→ View on sorbet.run](https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3ASig%0A%0Aclass%20Thing%0A%20%20def%20do_something%3B%20end%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example1(thing)%0A%20%20%23%20error%2C%20might%20be%20nil%3A%0A%20%20thing.do_something%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example2(thing)%0A%20%20if%20thing.nil%3F%0A%20%20%20%20raise%20%22The%20thing%20was%20nil%22%0A%20%20end%0A%0A%20%20%23%20no%20error%2C%20because%20it's%20after%20the%20%60if%20.nil%3F%60%20check%3A%0A%20%20thing.do_something%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example3(thing)%0A%20%20%23%20no%20error%2C%20because%20it's%20after%20the%20%60if%20.nil%3F%60%20check%3A%0A%20%20T.must(thing).do_something%0Aend) You can read more about `T.must` in the [Sorbet documentation](https://sorbet.org/docs/type-assertions#tmust). # Problem While `T.must` works, it is not ideal for a couple reasons: 1. It leads to a weird outward spiral of flow control, which disrupts method chains: ```ruby # ┌─────────────────┐ # │ ┌────┐ │ # ▼ ▼ │ │ T.must(T.must(task).mailing_params).fetch('template_context') # │ │ ▲ ▲ # │ └──────────┘ │ # └─────────────────────────────────┘ ``` compare that control flow with this: ```ruby # ┌────┐┌────┐┌─────────────┐┌────┐ # │ ▼│ ▼│ ▼│ ▼ task.must!.mailing_params.must!.fetch('template_context') ``` 2. It is not a method, so you can't `map` it over a list using `Symbol#to_proc`. Instead, you have to expand the block: ```ruby array_of_integers = array_of_nilable_integers.map {|x| T.must(x) } ``` Compare that with this: ```ruby array_of_integers = array_of_nilable_integers.map(&:must!) ``` 3. It is in a Sorbet-specific gem. We do not intend for Sorbet to be the only type checker. It would be nice to have such a method in the Ruby standard library so that it can be shared by all type checkers. 4. This method can make Ruby codebases that **don't** use type checkers more robust! `Kernel#must!` could be an easy way to assert invariants early. Failing early makes it more likely that a test will fail, rather than getting `TypeError`'s and `NoMethodError`'s in production. This makes all Ruby code better, not just the Ruby code using types. # Proposal We should extend the Ruby standard library with something like this:: ```ruby module Kernel def must!; self; end end class NilClass def must! raise TypeError.new("nil.must!") end end ``` These methods would get type annotations that look like this: (using Sorbet's RBI syntax, because I don't know RBS well yet) ```ruby module Kernel sig {returns(T.self_type)} def must!; end end class NilClass sig {returns(T.noreturn)} def must!; end end ``` What these annotations say: - In `Kernel#must!`, the return value is `T.self_type`, or "whatever the type of the receiver was." That means that `0.must!` will have type `Integer`, `"".must!` will have type `String`, etc. - In `NilClass#must!`, there is an override of `Kernel#must!` with return type `T.noreturn`. This is a fancy type that says "this code either infinitely loops or raises an exception." This is the name for Sorbet's [bottom type](https://en.wikipedia.org/wiki/Bottom_type), if you are familiar with that terminology. Here is a Sorbet example where you can see how these annotations behave: [→ View on sorbet.run](https://sorbet.run/#%23%20typed%3A%20true%0A%0Amodule%20Kernel%0A%20%20T%3A%3ASig%3A%3AWithoutRuntime.sig%20%7Breturns(T.self_type)%7D%0A%20%20def%20must!%3B%20self%3B%20end%0Aend%0A%0Aclass%20NilClass%0A%20%20T%3A%3ASig%3A%3AWithoutRuntime.sig%20%7Breturns(T.noreturn)%7D%0A%20%20def%20must!%0A%20%20%20%20raise%20TypeError.new(%22nil.must!%22)%0A%20%20end%0Aend%0A%0Axs%20%3D%20T%3A%3AArray%5BInteger%5D.new(%5B0%5D)%0AT.reveal_type(xs.first)%20%20%20%20%20%20%20%23%20T.nilable(Integer)%0AT.reveal_type(xs.first.must!)%20%23%20Integer%0A%0Ays%20%3D%20T%3A%3AArray%5BT.nilable(Integer)%5D.new(%5B0%2C%20nil%2C%201%2C%20nil%2C%202%5D)%0AT.reveal_type(ys)%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20T%3A%3AArray%5BT.nilable(Integer)%5D%0AT.reveal_type(ys.map(%26%3Amust!))%20%23%20T%3A%3AArray%5BInteger%5D) # Alternatives considered There was some discussion of this feature at the Feb 2020 Ruby Types discussion: Summarizing: - Sorbet team frequently recommends people to use `xs.fetch(0)` instead of `T.must(xs[0])` on `Array`'s and `Hash`'s because it chains and reads better. `.fetch` not available on other classes. - It's intentional that `T.must` requires as many characters as it does. Making it slightly annoying to type encourages developers to refactor their code so that `nil` never occurs. - There was a proposal to introduce new syntax like `thing.!!`. This is currently a syntax error. **Rebuttal**: There is burden to introducing new syntax. Tools like Rubocop, Sorbet, and syntax highlighting plugins have to be updated. Also: it is hard to search for on Google (as a new Ruby developer). Also: it is very short—having something slightly shorter makes people think about whether they want to type it out instead of changing the code so that `nil` can't occur. Another alternative would be to dismiss this as "not useful / common enough". I don't think that's true. Here are some statistics from Stripe's Ruby monolith (~10 million lines of code): | methood | percentage of files mentioning method | number of occurrences of method | | --- | --- | --- | | `.nil?` | 16.69% | 31340 | | `T.must` | 23.89% | 74742 | From this, we see that - `T.must` is in 1.43x more files than `.nil?` - `T.must` occurs 2.38x more often than `.nil?` # Naming I prefer `must!` because it is what the method in Sorbet is already called. I am open to naming suggestions. Please provide reasoning. # Discussion In the above example, I used `T.must` twice. An alternative way to have written that would have been using save navigation: ```ruby T.must(task&.mailing_params).fetch('template_context') ``` This works as well. The proposed `.must!` method works just as well when chaining methods with safe navigation: ```ruby task&.mailing_params.must!.fetch('template_context') ``` However, there is still merit in using `T.must` (or `.must!`) twice—it calls out that the programmer intended neither location to be `nil`. In fact, if this method had been chained across multiple lines, the backtrace would include line numbers saying specifically **which** `.must!` failed: ```ruby task.must! .mailing_params.must! .fetch('template_context') ``` -- https://bugs.ruby-lang.org/

1 0