Misc #21035: Clarify or redefine Module#autoload? and Module#const_defined?

• Status: Open
• Assignee: -

[fxn (Xavier Noria)]

The documentation for Module#autoload? says:

Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors.

As a user, if I declare an autoload, I expect this API:

module M
  autoload :Foo, 'foo'

  constants            # => [:Foo]
  const_defined?(:Foo) # => true
  autoload?(:Foo)      # => 'foo'
end

That it is indeed how it generally works. Even if the autoload path does not exist. But there is an edge case.

While constants does include always :Foo as far as I can tell, the return value of const_defined? and autoload? depends on the stack of features being loaded: The autoload path is resolved and if seen to be in the stack of features being loaded, the predicates return false and nil, respectively. Do you think that is intuitive?

I find that logic totally unexpected. I just defined an autoload, therefore, I think it would be natural for autoload? to return what I just configured. Why should const_defined? return nothing but true? And why is it not consistent with constants?

To me, it would make more sense that in the previous example const_defined? returns true, and autoload? returns foo unconditionally (and instantly, nowadays it takes a relative long time due to the lookup).

Now, if the autoload is triggered in a lookup then I would expect Kernel#require logic to apply. But not when calling some simple predicates.

Please, note that the present behavior is not documented, so on paper the change would not be backwards incompatible.

If, on the other side, it is preferred to keep the behavior as it is, I guess it should be documented with precision (accounting for symlinks, relative paths in $LOAD_PATH, etc.)