From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id C71A317D688C for ; Fri, 19 Jun 2015 11:02:55 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 8D71AB5D884 for ; Fri, 19 Jun 2015 11:25:48 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id C93B797A876 for ; Fri, 19 Jun 2015 11:25:49 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Authentication-Results: funfun.nagaokaut.ac.jp (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sendgrid.me Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc38sB0mxMuL for ; Fri, 19 Jun 2015 11:25:49 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 3550897A86E for ; Fri, 19 Jun 2015 11:25:49 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id C8052952443 for ; Fri, 19 Jun 2015 11:25:47 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id EC27D120478; Fri, 19 Jun 2015 11:25:45 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id 7FFE712046C for ; Fri, 19 Jun 2015 11:25:42 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=9IR5uYdjEGsBUhbiY7W6gvIZhhc=; b=j2Dm3y4lQCByFJfweH S93Jl8YVOCVaTF9ig7MLQLpXBzevpjdtJzI1aC3QaWKU619mX3jaygUBwjKS472y g76FVVpSertuNhgQpsJIuRrU3FzyP0fVXhAN9UsfHlT/5X7ug4nQreCtoqB7lg7V mdXAlfm2WvkqXyD0obausXy7o= Received: by filter0406p1mdw1.sendgrid.net with SMTP id filter0406p1mdw1.29428.55837D9EC 2015-06-19 02:25:38.072641428 +0000 UTC Received: from herokuapp.com (ec2-54-162-203-126.compute-1.amazonaws.com [54.162.203.126]) by ismtpd-038 (SG) with ESMTP id 14e09a2c194.3757.693d3 Fri, 19 Jun 2015 02:25:38 +0000 (UTC) Date: Fri, 19 Jun 2015 02:25:37 +0000 From: 0x0dea+redmine@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 44223 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11283 X-Redmine-Issue-Author: nepalez X-Redmine-Sender: 0x0dea X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5KfOMbMPJCxH09cgKg7I9pXLJNeV2RqrJBug hxR/5LVdGM/7W9L2SAuJLKRnf0sV7kheEXfiw3hbrAlxwLD6ULFbQAwwRWHKZoiU/O331OixkVRYaR sE6pQZYot/yltP84D17kCSkd1ole3nDNgIHT X-ML-Name: ruby-core X-Mail-Count: 69673 Subject: [ruby-core:69673] [Ruby trunk - Bug #11283] Block assigned implicitly X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11283 has been updated by D.E. Akers. > * Either provide a method with empty proc (`Proc.new`) That is, in fact, exactly what Ruby is doing: ```ruby def build Class.new { define_method :foo, Proc.new } end build{ :bar }.new.foo # => :bar ``` `Proc.new`, called without an explicit block, will instead attempt to use the one that was passed to the surrounding method: ```ruby def foo Proc.new.call 1 end foo { |x| x + 1 } # => 2 ``` Note well that methods need not explicitly declare that they take a block. This double whammy of implicit behavior is certainly "astonishing" the first time you encounter it, but it all hangs together in the final analysis. > * Or call `SyntaxError` as a strict way to ask for the programmer's intention This is a semantic rather than syntactic concern, and Ruby does warn against it. That it doesn't raise an `ArgumentError` as it does for standalone `Proc.new` is indeed unexpected, and may well be a bug. ---------------------------------------- Bug #11283: Block assigned implicitly https://bugs.ruby-lang.org/issues/11283#change-53033 * Author: Andrew Kozin * Status: Open * Priority: Normal * Assignee: * ruby -v: 1.9.3, 2.0, 2.1, 2.2, ruby-head * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- That is how it works: module Test def self.build(&block) klass = Class.new(Object) klass.__send__(:define_method, :foo) klass.__send__(:define_method, :bar) klass end end Tested = Test.build { :foo } # warning: tried to create Proc object without a block # => Tested Tested.new.foo # => :foo Tested.new.bar # => :foo The block is assigned to all calls to `:define_method` via `Object#__send__` implicitly, while it wasn't asked to. The behaviour is tested under MRI 1.9.3, 2.0, 2.1, 2.2, ruby-head. It doesn't occur under rbx-2 and jruby (1.7, 9.0.0.0). For the context look at this thread https://github.com/mbj/mutant/issues/356 -- https://bugs.ruby-lang.org/