ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:93502] [Ruby master Feature#15973] Make it so Kernel#lambda always return a lambda
Date: Tue, 02 Jul 2019 20:49:17 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-79060.20190702204917.3d1b122feb268bfb@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15973.20190702132050@ruby-lang.org

Issue #15973 has been updated by Eregon (Benoit Daloze).


I'm not sure changing this is good, because it can be very surprising for the code to change semantics dynamically.
Also, should `proc(&lambda)` make a non-lambda Proc then? It would be inconsistent if not.

As I said in https://bugs.ruby-lang.org/issues/15620#note-2, the current rule is AFAIK only change the semantics if a block is directly given, because the programmer means to use those semantics then.
If not, don't change the semantics as it would break the user (the Proc's code)'s intention.
The only exception to this is `define_method` with a pre-existing `Proc`, which is very rare, and understandably needed because methods should check arguments strictly. (maybe we don't need that exception)

I believe #15620 should be fixed on its own, it's a bug of the optimization.

Here is an example (a bit contrived, I'm tired):
```ruby
def foo(arg)
  early_check = Proc.new {
    # everything here assumes it will always be proc/non-lambda semantics
    return :early_return if arg > 3
  }

  # Some way for some external code to access `early_check`
  early_check = yield early_check

  early_check.call

  :method_return_value
end

p foo(4) { |pr| lambda(&pr) }
```

With current semantics, it returns `:early_return`.
With the proposed change, it returns `:method_return_value`.
That's very surprising, isn't it? The code clearly means it wants a non-local return to exit the method,
and yet somehow it was transformed into a local lambda return!

I think such a surprising transformation of user code should happen as little as possible, so I'm against this proposal.

Maybe we should simply forbid calling `proc`/`lambda` without a literal block (i.e., with an explicit Proc like `lambda(&pr)`), since it doesn't do anything useful ?
That would make more sense to me, and be in line with @ko1's recent changes to disallow things like `Proc.new`, etc without a block.

----------------------------------------
Feature #15973: Make it so Kernel#lambda always return a lambda
https://bugs.ruby-lang.org/issues/15973#change-79060

* Author: alanwu (Alan Wu)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
When Kernel#lambda receives a Proc that is not a lambda,
it returns it without modification. l propose changing `Kernel#lambda`
so it always returns a lambda.

Calling a method called lambda and having it effective do nothing was
not very intuitive.

https://github.com/ruby/ruby/pull/2262

Judging from marcandre's investigation here: https://bugs.ruby-lang.org/issues/15620#note-1
changing the behavior should not cause much breakage, if any. 


This also happens to fix [Bug #15620]



-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2019-07-02 20:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15973.20190702132050@ruby-lang.org>
2019-07-02 13:20 ` [ruby-core:93482] [Ruby master Feature#15973] Make Kernel#lambda always return lambda XrXr
2019-07-02 13:31 ` [ruby-core:93484] " matz
2019-07-02 20:49 ` eregontp [this message]
2019-07-03  2:03 ` [ruby-core:93506] [Ruby master Feature#15973] Make it so Kernel#lambda always return a lambda shyouhei
2019-07-08  0:20 ` [ruby-core:93597] " XrXr
2019-07-08  0:35 ` [ruby-core:93598] " XrXr
2019-07-08 13:49 ` [ruby-core:93615] " shyouhei
2019-07-09 14:32 ` [ruby-core:93635] " XrXr
2019-07-09 14:38 ` [ruby-core:93636] " eregontp
2019-07-11  5:20 ` [ruby-core:93661] " akr
2019-07-11  8:18 ` [ruby-core:93674] " matz
2019-07-11 10:00 ` [ruby-core:93679] " knu
2019-07-11 11:57 ` [ruby-core:93682] " ruby-core
2019-07-11 16:27 ` [ruby-core:93692] " shyouhei
2019-07-12  4:11 ` [ruby-core:93708] " XrXr
2019-07-12  5:31 ` [ruby-core:93711] " shyouhei
2019-07-12  5:43 ` [ruby-core:93712] " akr
2019-07-12  9:30 ` [ruby-core:93717] " eregontp
2019-07-17 21:20 ` [ruby-core:93822] " XrXr
2019-07-26 17:53 ` [ruby-core:93935] " daniel
2019-07-30  8:08 ` [ruby-core:94038] " ko1
2019-07-30 13:31 ` [ruby-core:94054] " matz
2019-07-30 16:32 ` [ruby-core:94058] " daniel
2019-08-05 16:04 ` [ruby-core:94150] " daniel
2019-09-28  3:46 ` [ruby-core:95140] [Ruby master Feature#15973] Let " XrXr
2019-12-21 21:09 ` [ruby-core:96397] " eregontp
2019-12-24 17:35 ` [ruby-core:96459] " ko1
2019-12-24 17:37 ` [ruby-core:96460] " ko1
2019-12-25 11:04 ` [ruby-core:96463] " eregontp
2019-12-25 11:13 ` [ruby-core:96464] " eregontp
2019-12-25 11:15 ` [ruby-core:96465] " eregontp
2019-12-25 11:20 ` [ruby-core:96467] " zverok.offline
2019-12-25 11:51 ` [ruby-core:96469] " eregontp
2019-12-25 19:34 ` [ruby-core:96475] " zverok.offline
2019-12-26  7:49   ` [ruby-core:96490] " atdot
2019-12-26 20:46 ` [ruby-core:96500] " daniel
2020-01-10 22:21 ` [ruby-core:96767] " eregontp
2020-01-16  8:12 ` [ruby-core:96900] " ko1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-79060.20190702204917.3d1b122feb268bfb@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).