https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112019-04-07T13:56:47ZRuby Issue Tracking SystemRuby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775032019-04-07T13:56:47ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/15743">Feature #15743</a>: RubyVM should be renamed to CRuby</i> added</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775042019-04-07T13:58:27ZEregon (Benoit Daloze)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/77504/diff?detail_id=51567">diff</a>)</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775162019-04-08T01:26:26Zioquatix (Samuel Williams)samuel@oriontransfer.net
<ul></ul><p>I think it's a good idea. Might I suggest two potential ideas?</p>
<p>Firstly, maybe have a shared <code>Ruby</code> module for common but interpreter specific functionality.</p>
<p>Then, interpreter specific modules e.g. <code>CRuby</code>, <code>MRuby</code>, <code>JRuby</code>, <code>TruffleRuby</code> for interpreter specific functionality.</p>
<p>For experimental stuff, you could choose either <code>CRuby::Experimental</code> or <code>Ruby::Experimental</code>. The path for loading such features would be <code>require 'ruby/experimental/thing'</code>.</p>
<p>Maybe also worthwhile considering how Python's <code>__future__</code> works, e.g. <a href="https://stackoverflow.com/questions/7075082/what-is-future-in-python-used-for-and-how-when-to-use-it-and-how-it-works" class="external">https://stackoverflow.com/questions/7075082/what-is-future-in-python-used-for-and-how-when-to-use-it-and-how-it-works</a> is a quick overview if anyone is unfamiliar.</p>
<p>+1</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775292019-04-08T09:31:06ZEregon (Benoit Daloze)
<ul></ul><p>ioquatix (Samuel Williams) wrote:</p>
<blockquote>
<p>I think it's a good idea. Might I suggest two potential ideas?</p>
</blockquote>
<p>Go ahead :)</p>
<blockquote>
<p>Firstly, maybe have a shared <code>Ruby</code> module for common but interpreter specific functionality.</p>
</blockquote>
<p>This is equivalent to my proposition of <code>ExperimentalFeatures</code> with a different name, right?</p>
<p>I don't understand how it can be "common" and also "interpreter specific". They are opposite to me. Did you mean "but not"?</p>
<blockquote>
<p>Then, interpreter specific modules e.g. <code>CRuby</code>, <code>MRuby</code>, <code>JRuby</code>, <code>TruffleRuby</code> for interpreter specific functionality.</p>
<p>For experimental stuff, you could choose either <code>CRuby::Experimental</code> or <code>Ruby::Experimental</code>.</p>
</blockquote>
<p>I was thinking both the common namespace and the interpreter-specific namespaces are experimental.<br>
But indeed, maybe we need to be more fine-grained.</p>
<p>For instance, TruffleRuby defines a few methods and classes under <code>TruffleRuby</code> and those are fairly stable and documented.<br>
<a href="https://github.com/oracle/truffleruby/blob/master/doc/user/truffleruby-additions.md#truffleruby-methods-and-classes" class="external">https://github.com/oracle/truffleruby/blob/master/doc/user/truffleruby-additions.md#truffleruby-methods-and-classes</a><br>
BTW, a few of those would probably make sense under <code>ExperimentalFeatures</code> (most of these are needed by ConcurrentRuby).</p>
<p>I think anything under <code>ExperimentalFeatures</code> is experimental.<br>
Common stable (non-experimental) features should just be under another namespace (e.g., Kernel or whatever feels appropriate, including possibly a new class/module for the feature).</p>
<p>For interpreter-specific namespaces, I think it's OK to delegate to the documentation of the implementation to say what's experimental and what's stable,<br>
although the distinction should be simple such as <code>TruffleRuby</code> would be stable and <code>TruffleRuby::Experimental</code> would be experimental.</p>
<p>I think <code>CRuby::Experimental</code> would be good (as a replacement for <code>RubyVM</code>), because it clearly marks such API are MRI specific and have not matured to a stable API yet.<br>
Just as an example, <code>RubyVM::AbstractSyntaxTree</code> will probably break usages of it whenever a node field is added, removed or reordered,<br>
so being clearly marked as experimental in the usages seems good (<a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Future of RubyVM::AST? (Open)" href="https://bugs.ruby-lang.org/issues/14844">#14844</a> is an example that this is not clear at all for users currently with <code>RubyVM</code>).</p>
<blockquote>
<p>The path for loading such features would be <code>require 'ruby/experimental/thing'</code>.</p>
</blockquote>
<p>Typically the require is not needed, such functionality is just declared from startup.<br>
That's the case for JRuby, TruffleRuby and Rubinius.<br>
I'm not against it, but I don't see what it solves.<br>
For feature checking, <code>defined?(ExperimentalFeatures.foo)</code> (or <code>respond_to?</code>) seems good enough.</p>
<blockquote>
<p>Maybe also worthwhile considering how Python's <code>__future__</code> works, e.g. <a href="https://stackoverflow.com/questions/7075082/what-is-future-in-python-used-for-and-how-when-to-use-it-and-how-it-works" class="external">https://stackoverflow.com/questions/7075082/what-is-future-in-python-used-for-and-how-when-to-use-it-and-how-it-works</a> is a quick overview if anyone is unfamiliar.</p>
</blockquote>
<p>How would that work in Ruby?<br>
It seems more targeted at trying to make code more compatible with more recent versions, which I think we simply do by deprecation in Ruby and not breaking syntax.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775312019-04-08T09:54:35Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>Web browsers showed us that it cannot achieve at once both experimental and portable.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775332019-04-08T11:41:57Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>One worry that I have here is that this change may add bureaucratic overhead to MRI in<br>
particular. I have nothing against alternative ruby implementations at all, quite the<br>
opposite - the easier it is to implement ruby/rubies the better. The core team also<br>
tried to help here, e. g. ISO spec of ruby; and alternative implementations also<br>
helped likewise the other way around, such as rubinius + ruby spec early on (and still<br>
maintained, also by ruby contributors; I think Benoit extended the spec too, and this<br>
may be a partial reason for the suggestion perhaps). But having a situation where changes<br>
to MRI could possibly be delayed due to difficulties of alternative implementations would<br>
be a bad thing too, in my opinion. I think most people use MRI and any change to MRI in<br>
this regard should also be kept in mind.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775352019-04-08T11:49:54ZEregon (Benoit Daloze)
<ul></ul><p>naruse (Yui NARUSE) wrote:</p>
<blockquote>
<p>Web browsers showed us that it cannot achieve at once both experimental and portable.</p>
</blockquote>
<p>I will dare to challenge that.<br>
Why would <code>ExperimentalFeatures.resolve_feature_path</code> not be portable?<br>
Portable here just means it <em>can</em> be implemented by other Ruby implementations,<br>
and it is designed to not be specific to a given implementation (i.e., it can be implemented on other Ruby implementations).</p>
<p>Re browsers, I think the main problem is every browser used their own prefixes.<br>
If we use a common namespace, and discuss all additions in this tracker, I don't think we'll have that problem.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775362019-04-08T11:52:24ZEregon (Benoit Daloze)
<ul></ul><p>shevegen (Robert A. Heiler) wrote:</p>
<blockquote>
<p>But having a situation where changes to MRI could possibly be delayed due to difficulties<br>
of alternative implementations would be a bad thing too, in my opinion.</p>
</blockquote>
<p>I am not proposing anything like that.<br>
Practically, whenever MRI decides to add an experimental feature,<br>
the only change is if it could potentially be implemented on other Ruby implementations ("portable" as I just defined above),<br>
add it under <code>ExperimentalFeatures</code> instead of under <code>RubyVM</code>. That's all.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=775422019-04-08T18:02:22ZEregon (Benoit Daloze)
<ul><li><strong>Subject</strong> changed from <i>A dedicated module for portable experimental features</i> to <i>A dedicated module for experimental features</i></li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=776572019-04-17T08:19:07Zknu (Akinori MUSHA)knu@ruby-lang.org
<ul></ul><p>Using a plural constant name sounds like a good idea because it wouldn't likely conflict with existing model names. 😄</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=776582019-04-17T08:27:24Zknu (Akinori MUSHA)knu@ruby-lang.org
<ul></ul><p>I think it's a good idea to reserve a namespace globally shared among Ruby implementations, even if it's up to each implementation whether to follow individual features proposed by other implementations.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=783632019-06-05T20:14:18ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/15903">Feature #15903</a>: Move RubyVM.resolve_feature_path to Kernel.resolve_feature_path</i> added</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=789772019-06-30T12:26:48ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-4 priority-default closed" href="/issues/15966">Feature #15966</a>: Introducing experimental features behind a flag, disabled by default</i> added</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=831232019-12-14T11:06:50ZEregon (Benoit Daloze)
<ul></ul><p>FWIW, Java has such a concept too that they call "incubator modules" and basically just have the new experimental API under <code>jdk.incubator</code> (<a href="https://www.azul.com/openjdk-more-speed-less-haste/" class="external">https://www.azul.com/openjdk-more-speed-less-haste/</a> for details).</p>
<p>I think we should introduce <code>ExperimentalFeatures</code> in Ruby, it's so much clearer than RubyVM (which is also problematic, see above).</p>
<p>Since we can't really agree on what <code>RubyVM</code> is (currently a mix of stable and less stable APIs),<br>
I think <code>RubyVM</code> should just becoming a supported module like the rest of the core API,<br>
and only <code>ExperimentalFeatures</code> should have this special status for experimental APIs.<br>
Thoughts?</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=868892020-08-01T13:01:14ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-4 priority-default" href="/issues/14844">Feature #14844</a>: Future of RubyVM::AST? </i> added</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=868912020-08-01T13:25:53ZEregon (Benoit Daloze)
<ul></ul><p>The existence of <code>RubyVM</code> prevents other Ruby implementations to be fully 100% compatible, because more and more gems start to rely on it.<br>
So either:</p>
<ul>
<li>We move most of <code>RubyVM</code> to <code>ExperimentalFeatures</code> so that other Ruby implementations can implement it for compatibility (e.g., <code>AbstractSyntaxTree</code>, <code>InstructionSequence</code>).<br>
That also gives a nice way to experiment with not-yet-stable features/APIs.</li>
<li>We are fine that other Ruby implementations have a <code>RubyVM</code> constant too. That will make it even less clear that <code>RubyVM</code> is experimental.</li>
</ul>
<p>In practice, if CRuby exposes any API, then some gems might rely on it and with enough gems it becomes hard/impossible to remove it.<br>
So if CRuby wants extra API for e.g. internal VM debugging, it should be added only with some special <code>./configure</code> flag.<br>
That I think is the only way to prevent gems to (probably unknowingly) depend on CRuby-private APIs that are not meant to be used except for CRuby internal debugging.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=868932020-08-01T13:29:18ZEregon (Benoit Daloze)
<ul></ul><p>To clarify, by "move" I mean moving under <code>ExperimentalFeatures</code> but we could still e.g. have a deprecated constant under RubyVM to help transition.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=869192020-08-03T19:04:41ZDan0042 (Daniel DeLorme)
<ul></ul><p>Can I ask what would be so bad about having the <code>RubyVM</code> constant in other implementations? I mean, in itself the name is very general. Every implementation can be said to be a "Ruby VM".</p>
<p>If support for an experimental feature is indicated by <code>RubyVM.has_feature_xyz?</code>, an implementation can choose to return <code>false</code> for the moment. When the feature moves past the experimental stage the implementation can add it, and <code>RubyVM.has_feature_xyz?</code> can return true, and there's no need to move it out of the <code>ExperimentalFeatures</code> namespace.</p>
<p><em>If</em> the intention is to rename <code>RubyVM::AbstractSyntaxTree</code> to <code>AbstractSyntaxTree</code> once it's no longer experimental, then I agree it would make more sense as <code>Experimental::AbstractSyntaxTree</code>. But if <code>RubyVM::AbstractSyntaxTree</code> is intended as the final name then temporarily stuffing it into an <code>Experimental</code> namespace would be way more trouble than it's worth.</p>
<p>Honestly asking: what is the benefit of messing around with what seems to have become a de-facto standard?</p>
<p>(apologies in advance if I missed the point of all this)</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=869202020-08-03T19:34:02ZEregon (Benoit Daloze)
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote in <a href="#note-18">#note-18</a>:</p>
<blockquote>
<p>Can I ask what would be so bad about having the <code>RubyVM</code> constant in other implementations? I mean, in itself the name is very general. Every implementation can be said to be a "Ruby VM".</p>
</blockquote>
<p>It's a good question. My understanding is that <code>RubyVM</code> was really meant as the <code>JRuby</code> or <code>TruffleRuby</code> module of JRuby/TruffleRuby, i.e., a module specifically for CRuby-specific things.<br>
I tried to rename it to CRuby for clarity in <a href="https://bugs.ruby-lang.org/issues/15743" class="external">https://bugs.ruby-lang.org/issues/15743</a> but failed: <a href="https://bugs.ruby-lang.org/issues/15743#note-21" class="external">https://bugs.ruby-lang.org/issues/15743#note-21</a></p>
<p>See also <a href="https://bugs.ruby-lang.org/issues/15743#note-7" class="external">https://bugs.ruby-lang.org/issues/15743#note-7</a> which notes that about everything under <code>RubyVM</code> was meant to be CRuby-specific.<br>
But since CRuby is the standard implementation, about any public API, including RubyVM will become used and depended on.<br>
Even more so if the name doesn't imply "experimental/unstable".</p>
<p>I would like experimental APIs to be clearly marked as such, and RubyVM doesn't achieve that well at all.<br>
In fact I would bet many users of RubyVM don't even know it's experimental, or don't even know it's CRuby-specific (I tried to document that, but people don't read the documentation all the time).</p>
<p>So if RubyVM becomes shared it will become clear it's no longer CRuby-specific experiments.<br>
I'm fine with that, because RubyVM is already used in production by now (e.g., bootsnap).</p>
<p>I think as a result CRuby will no longer have a module for experimental features then.<br>
Not necessarily a bad thing, as truly experimental APIs should probably be behind a <code>./configure</code> flag if developers are serious about not having gems depend on it.<br>
And I think it's good that new APIs, even if experimental, consider about portability since we have more than 1 implementation in the Ruby ecosystem.</p>
<p>Adding <code>ExperimentalFeatures</code> would let CRuby and other implementations experiment in a shared namespace, which seems clearer for everybody.<br>
It wouldn't prevent gems to depend on it, but at least the name clearly states the intention.</p>
<p>So, in summary I don't really mind either way.</p>
<p>I think if we make <code>RubyVM</code> a shared namespace then CRuby will need another module/way for experimental/CRuby-specific features.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=869212020-08-03T19:40:33ZEregon (Benoit Daloze)
<ul></ul><p>I think an important lesson the Ruby implementors have learned over time is that there are no CRuby-specific APIs, it's a myth.<br>
Whatever was thought once as CRuby-specific will eventually be implemented on some other Ruby implementation, because they need it for compatibility.</p>
<p>There is definitely a need to introduce experimental not-yet-matured APIs.<br>
RubyVM is not a great place for that, as experimental APIs might be completely unrelated to the VM.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=869232020-08-04T00:19:47Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>FYI: <a href="https://github.com/mame/ruby-type-profiler" class="external">Type-profiler</a>, which I'm developing for an experimental type inference tool for Ruby 3 types, heavily depends upon <code>RubyVM::InstructionSequence</code> because it performs static analysis on MRI byte code.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=870712020-08-15T10:20:01ZEregon (Benoit Daloze)
<ul></ul><p>mame (Yusuke Endoh) wrote in <a href="#note-21">#note-21</a>:</p>
<blockquote>
<p>FYI: <a href="https://github.com/mame/ruby-type-profiler" class="external">Type-profiler</a>, which I'm developing for an experimental type inference tool for Ruby 3 types, heavily depends upon <code>RubyVM::InstructionSequence</code> because it performs static analysis on MRI byte code.</p>
</blockquote>
<p>Is there a reason to use bytecode instead of the AST (e.g., from <code>parser</code> or <code>RubyVM::AbstractSyntaxTree</code> which can be portable), which has more information?<br>
It seems suboptimal to me to have any "Ruby 3 types project" depend on something like <code>RubyVM::InstructionSequence</code>, that will make it practically impossible to work on alternative Ruby implementations.<br>
Also the bytecodes change regularly, so this will probably regularly break any project depending on it.</p>
<p>Note that it is orthogonal to this issue, any library using RubyVM could switch to ExperimentalFeatures easily (by <code>ExperimentalFeatures = RubyVM unless defined?(ExperimentalFeatures)</code>).</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=873362020-09-01T08:06:08Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>As far as I understand, you want a place to separate features that do not only belong to <code>CRuby</code>, right?<br>
But for example, we started <code>RubyVM::AbstractSyntaxTree</code> as a <code>CRuby</code> specific feature, it was natural for us to place it under <code>RubyVM</code>.<br>
So it may be uncertain that the feature is implementation-specific or not from the start. So we have to discuss for each feature that can be shared among implementations (like <code>RubyVM::AbstractSyntaxTree</code>). We might give it a new name. In my opinion, we don't need a place like <code>ExperimentalFeature</code>, because it is not what we really need.</p>
<p>Matz.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=896862021-01-01T12:43:33ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-4 priority-default closed" href="/issues/17500">Feature #17500</a>: Move RubyVM::* to ExperimentalFeatures</i> added</li></ul> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=901312021-01-28T21:01:51ZEregon (Benoit Daloze)
<ul><li><strong>Status</strong> changed from <i>Closed</i> to <i>Open</i></li></ul><p>See <a href="https://bugs.ruby-lang.org/issues/17500#note-8" class="external">https://bugs.ruby-lang.org/issues/17500#note-8</a></p>
<p>I think it is very clear MRI (and other Ruby implementations as well) need a place to put new experimental APIs.</p>
<p>Right now, RubyVM is used for new experimental APIs, but that's unclear for users, and over time it won't be considered experimental or MRI-specific at all (see linked comment).<br>
<code>RubyVM</code> can already not be considered experimental anymore, because e.g., <code>RubyVM::InstructionSequence</code> and <code>RubyVM::AbstractSyntaxTree</code> are used in gems.</p>
<p>So, how about adding an <code>Experimental</code> or <code>ExperimentalFeatures</code> module, and add new experimental APIs there, <em>instead</em> of in RubyVM?</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=901332021-01-29T04:14:29Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>We consumed about this topic too long. I want this topic as pending in a year.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=904162021-02-16T06:54:13Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>Repeating myself, I don't think we need a place for experimental features. If we put experimental features in a certain place, we need to rewrite our programs when the feature graduated from the experimental state. It would be a pain for users who participate in experiments.</p>
<p>Matz.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=904332021-02-16T12:01:53ZEregon (Benoit Daloze)
<ul></ul><p>matz (Yukihiro Matsumoto) wrote in <a href="#note-27">#note-27</a>:</p>
<blockquote>
<p>If we put experimental features in a certain place, we need to rewrite our programs when the feature graduated from the experimental state. It would be a pain for users who participate in experiments.</p>
</blockquote>
<p>This is already the case with RubyVM, which is currently used for at least some experimental features, so this argument is baseless (features that are under RubyVM and become no longer experimental should be moved too, e.g., RubyVM::AbstractSyntaxTree is just a temporary long name which intends to show it's experimental).</p>
<p>So I'm only asking that next time we think about adding some experimental feature under <code>RubyVM</code>, we add it under <code>Experimental</code> instead.<br>
Does that sounds reasonable?<br>
As I said, nobody knows if some API will always be MRI-specific, so RubyVM is a bad place anyway and has no advantages, it just confuses everyone.</p>
<p>If ruby-core doesn't want to do this, for me it's clear: RubyVM becomes de facto no longer experimental and no longer MRI-specific.<br>
Everyone loses there: MRI doesn't have a place for MRI-specific or for experimental APIs anymore, users won't know what RubyVM is supposed to mean, and other Ruby implementations will likely need to be compatible to all APIs under RubyVM, just like any other core library API.</p> Ruby master - Feature #15752: A dedicated module for experimental featureshttps://bugs.ruby-lang.org/issues/15752?journal_id=909592021-03-17T04:38:48Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>We consumed about this topic too long. I want this topic as pending in a year.</p>