Feature #20884: reserve "Ruby" toplevel module for Ruby language

• Status: Open
• Assignee: -
• Target version: -

[Dan0042 (Daniel DeLorme)]

Ruby would be a convenient namespace for many features of the Ruby language, in particular APIs related to the interpreter.

All these constants:

RUBY_VERSION
RUBY_RELEASE_DATE
RUBY_PLATFORM
RUBY_PATCHLEVEL
RUBY_REVISION
RUBY_COPYRIGHT
RUBY_ENGINE
RUBY_ENGINE_VERSION
RUBY_DESCRIPTION

would have made a lot of sense as Ruby::VERSION etc.

Thread::Backtrace::Location would have made a lot of sense as Ruby::Backtrace::Location

RubyVM is considered specific to CRuby; so RubyVM::AbstractSyntaxTree should be Ruby::AbstractSyntaxTree if it is meant to be present in other implementations.

In #6648 there's a bit of contention over where ruby_args should be. RubyVM, RbConfig, Process have all been proposed, but Ruby would be an excellent choice.

Process.argv0 was added in Ruby 2.1 but the Process namespace is really about OS-level process control (fork, signals, euid, limits) while this argv0 is not (in ps it's neither value of COMMAND nor CMD) so it would have made sense as Ruby.argv0

The "ruby" gem name is reserved, so there's no conflict. https://rubygems.org/gems/ruby

All in all, "Ruby" is an appropriate namespace for many Ruby things. We don't want to break compatibility over this, but we could at least start small by reserving the namespace, and see how it grows from there.

module Ruby
  VERSION = ::RUBY_VERSION
end

[ioquatix (Samuel Williams)]

+1.

However, if we introduce it, can we also introduce a document to guide the evolution, e.g. naming conventions, in scope and out of scope usage, etc. I suppose I'd expect constants to be upper case still, e.g. Ruby::VERSION.

[hsbt (Hiroshi SHIBATA)]

I prefer this proposal.

The "ruby" gem name is reserved, so there's no conflict. https://rubygems.org/gems/ruby

FYI: I'm an owner of ruby gem.

I suppose I'd expect constants to be upper case still, e.g. Ruby::VERSION.

+1

[Eregon (Benoit Daloze)]

I think this is a great idea, and would allow to introduce some methods/constants/modules/classes we wouldn't be able to otherwise due to concerns of conflicting with existing constants.

I think it would be a good place for:

• a method returning the ruby executable, there is currently RbConfig.ruby and Gem.ruby but neither are the right place for it.
• a method returning the main ruby script, Process.argv0 is so confusing.
• a method returning the original ruby interpreter options (#6648)
• a method returning the original user-level arguments, i.e. the initial deeply-copied value of ARGV (#6648)
• a method returning the original working directory, as a String, i.e. the initial value of Dir.pwd (#6648)
• a class like SourceLocation/CodeLocation with start_{line,column,offset}, end_{line,column,offset} and code/source for https://bugs.ruby-lang.org/issues/6012#note-19

Thread::Backtrace::Location would have made a lot of sense as Ruby::Backtrace::Location

Agreed.

RubyVM is considered specific to CRuby; so RubyVM::AbstractSyntaxTree should be Ruby::AbstractSyntaxTree if it is meant to be present in other implementations.

AbstractSyntaxTree is parse.y-specific and CRuby-specific, so that's not a good example. There is already Prism as the official and portable API to deal with Ruby ASTs.
But indeed sometimes there were suggestions to add methods to RubyVM which are not CRuby-specific (e.g. RubyVM.resolve_feature_path in #15903), which is a problem as RubyVM can only exist on CRuby, as many gems rely on defined?(RubyVM) == CRuby or things like assuming RubyVM::InstructionSequence exists if defined?(RubyVM).
Adding it under Ruby makes it possible for other Ruby implementations to implement it, which is essential for any new functionality which can be implemented on other Ruby implementations.

From a quick look at RubyVM, I think keep_script_lines{,=} could/should be moved, the rest does look truly CRuby-specific (specific JITs of CRuby, CRuby-specific bytecode, CRuby-specific VM options).

Regarding RUBY_* constants I'm not sure there is much value to copy them under Ruby as backward-compatible code can't use them for a while, but I don't mind it either (they should stay uppercase though, I'd suggest to update the description to use Ruby::VERSION).

[Dan0042 (Daniel DeLorme)]

• Description updated (diff)

[Dan0042 (Daniel DeLorme)]

• Description updated (diff)

Eregon (Benoit Daloze) wrote in #note-3:

I'd suggest to update the description to use Ruby::VERSION).

Ok, did that.

[matz (Yukihiro Matsumoto)]

It's OK for me to reserve Ruby constant (module) for the future. It should only contain portable information among implementations.

Matz.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

Applied in changeset git|4d86f3bf6d1fe7bf7d4b25fc42f7aba9f401bbb4.

---

[Feature #20884] Reserve "Ruby" toplevel name

[hsbt (Hiroshi SHIBATA)]

• Status changed from Closed to Open

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

Applied in changeset git|197a3efc751f43956fc9ad30d688b4bfa3f7fbdb.

---

[Feature #20884] News of toplevel "Ruby" name reservation

[hsbt (Hiroshi SHIBATA)]

• Status changed from Closed to Open

[mame (Yusuke Endoh)]

Discussed at the dev meeting.

@matz (Yukihiro Matsumoto) decided that Ruby 3.4 warns when ::Ruby is defined.

$ ./miniruby -we 'Ruby = 1'
-e:1: warning: ::Ruby is reserved for Ruby 3.5

If there are no major problems, it is likely that module Ruby will be predefined in Ruby 3.5.

However, note that what to put in the ::Ruby module requires futher discussion.

• Ruby::Backtrace::Location was opposed by nobu.
• AbstractSyntaxTree is in RubyVM to make it explicitly implementation-dependent, so it will not be moved to Ruby::.
• No one sympathized with Ruby.argv0 in the dev meeting. Process.argv0 is good enough.
• #6648 is not agreed at the specification level, and I think it is unlikely to be a class method in ::Ruby.