From: "Dan0042 (Daniel DeLorme) via ruby-core" Date: 2023-08-22T12:50:27+00:00 Subject: [ruby-core:114443] [Ruby master Misc#19777] Make `Kernel#lambda` raise when called without a literal block Issue #19777 has been updated by Dan0042 (Daniel DeLorme). The ship has sailed, but I should at least mention I am disappointed at this turn of things. Again deprecating things for no concrete benefit. How ironic that #15973 started with "change Kernel#lambda so it always returns a lambda" and ended with "let's make sure people can't do that". ---------------------------------------- Misc #19777: Make `Kernel#lambda` raise when called without a literal block https://bugs.ruby-lang.org/issues/19777#change-104200 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal ---------------------------------------- Since 3.0.0, released in 2020, calling `Kernel#lambda` without a literal block has been issuing a deprecation warning: ```ruby Warning[:deprecated] = true def foo(&b) lambda(&b) end foo {} # => test.rb:2: warning: lambda without a literal block is deprecated; use the proc without lambda instead ``` I think enough time has passed and we should make it raise in all situations where it currently issues a deprecation warning. The original decision to deprecate is here: https://bugs.ruby-lang.org/issues/15973#note-46 The new behavior allows one to predict whether `Kernel#lambda` will return by inspecting its direct caller, checking whether the call site has a literal block. It will remove some hard-to-predict cases where `Kernel#lambda` receives a non-literal block forwarded with `super` or `rb_funcall_passing_block`. The method will always return a lambda, if it returns. However, note that `send` will be a special exception in this new model: ```ruby Warning[:deprecated] = true singleton_class.send(:public, :lambda) p (send(:lambda) {}).lambda? # => true without warning p (public_send(:lambda) {}).lambda? # => true with warning, would raise instead ``` This newer model is friendlier to some optimization we're investigating for YJIT as it has fewer moving parts. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/