Issue #10488 has been updated by Benoit Daloze.

Status changed from Open to Closed

Indeed, it looks consistent with `const_get` and it seems difficult to be more consistent while keeping the same API.
Let's close this then.

----------------------------------------
Bug #10488: Consistency of Module#const_defined? and constant lookup
https://bugs.ruby-lang.org/issues/10488#change-50106

* Author: Benoit Daloze
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: core
* Target version: current: 2.2.0
* ruby -v: ruby 2.2.0dev (2014-10-12 trunk 47890) [x86_64-darwin13]
* Backport: 
----------------------------------------
Currently, if for some module `mod` and constant `Const`,
`mod.const_defined?(:Const)` is true does not imply `mod::Const` is not an error.

This is inconsistent for at least the following cases:

* if mod is a Module but not a class, `const_defined?` will look in `Object` and its ancestors, but constant access (::) will not look in `Object` or above.

    ~~~ruby
    Enumerable.const_defined? :String
    Enumerable::String #=> NameError: uninitialized constant Enumerable::String

* if `Const` is private, `const_defined?` will return true while `mod::Const` will raise an error.

    ~~~ruby
    C = 42
    Object.private_constant :C
    String.const_defined? :C #=> true
    String::C #=> NameError: private constant String::C referenced

    # This works, but is due to the lexical scope lookup
    class String
      C #=> 42
    end

Is this intended?
Should it not mirror the behavior of `defined?(mod::Const)`?
Or the behavior of `method_defined?`




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