From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 2A3411F4B4 for ; Thu, 28 Jan 2021 21:01:57 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 90F521209E0; Fri, 29 Jan 2021 06:01:04 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 278371209DB for ; Fri, 29 Jan 2021 06:01:01 +0900 (JST) Received: by filterdrecv-p3iad2-759c955dc9-vqg6m with SMTP id filterdrecv-p3iad2-759c955dc9-vqg6m-18-6013263F-6E 2021-01-28 21:01:51.603003147 +0000 UTC m=+4152.593921744 Received: from herokuapp.com (unknown) by ismtpd0007p1iad2.sendgrid.net (SG) with ESMTP id Xx4ug3w8Q269NlvNI6ZY0A for ; Thu, 28 Jan 2021 21:01:51.566 +0000 (UTC) Date: Thu, 28 Jan 2021 21:01:51 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 78190 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 15752 X-Redmine-Issue-Author: Eregon X-Redmine-Sender: Eregon 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: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr2XHgfY4XWGpSmBoLV5xk?= =?us-ascii?Q?kdQ9ZCReF0jz20AYvKmeGIQKYPSH2j+cR5gxtnR?= =?us-ascii?Q?=2FpX3jMzH8S3HI1C6CTPZu+X9PM25=2F8jsPW9HQUM?= =?us-ascii?Q?9lizcW5Vk7MZ0rOHA5uSTfdq8mTGEUc7sjr591Y?= =?us-ascii?Q?nZvXSbXsi+TxpX1aj8KzrN7SnO7g10dJZMBjyBs?= =?us-ascii?Q?ZJYfzV3rDBZ7cTlYc=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 102278 Subject: [ruby-core:102278] [Ruby master Feature#15752] A dedicated module for experimental features 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15752 has been updated by Eregon (Benoit Daloze). Status changed from Closed to Open See https://bugs.ruby-lang.org/issues/17500#note-8 I think it is very clear MRI (and other Ruby implementations as well) need a place to put new experimental APIs. 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). `RubyVM` can already not be considered experimental anymore, because e.g., `RubyVM::InstructionSequence` and `RubyVM::AbstractSyntaxTree` are used in gems. So, how about adding an `Experimental` or `ExperimentalFeatures` module, and add new experimental APIs there, *instead* of in RubyVM? ---------------------------------------- Feature #15752: A dedicated module for experimental features https://bugs.ruby-lang.org/issues/15752#change-90131 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- I believe we should introduce a module for experimental features portable across Ruby implementations. An example of such a portable experimental feature is `RubyVM.resolve_feature_path`. This feature has nothing MRI specific in it, it is a part of basic `require` functionality. In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it. Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features. This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users), and keeping `RubyVM` not defined for clearly marking MRI specific features are not available. This is a problem that will only gets worse as portable experimental features are added to `RubyVM`. Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it: https://github.com/jruby/jruby/issues/5206 If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific, which would be very confusing to both users and Ruby implementers. Also, `RubyVM` doesn't really indicate by its name that it contains experimental features. So I propose the obvious name `ExperimentalFeatures`. I think such a long name is unlikely to clash with existing Object constants, is very clear, and marks that any usage of it is by definition using not stable APIs that might be removed or changed. In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming: * `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too. * `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI. OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable. My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features. There is no reason for only MRI to be able to support code using portable experimental features. cc @mame @headius -- https://bugs.ruby-lang.org/