Issue #15966 has been updated by Eregon (Benoit Daloze).


ioquatix (Samuel Williams) wrote:
> I think there are two separate concerns that have been raised in this issue.

Thank you for your reply.

> Point 1 is relatively straight forward and anyone can choose to introduce new "optional" feature.

I think we need to not overuse it, like @jeremyevans0 said.
Features which are not experimental or unlikely to get major concerns should probably not use it.
E.g. the proposed `Fiber::Pool` probably needs a discussion about potential namespace issues and methods naming, but I think it doesn't need a lot of feedback before being stable.
It's a lot easier to evolve methods than syntax, too. I think #15752 is a simpler way for new experimental methods/modules.

> This could be discussed and agreed on relatively easily I think, with a standard format used in `configure.ac`.

Note that I propose to add a runtime flag, not a ./configure flag. I initially thought about a ./configure flag but:
* that doesn't let end users conveniently experiment with it, they would have to rebuild a second time with the flag.
* there is no ./configure for JRuby, TruffleRuby and probably other implementations.

> Another option beyond what has been proposed is to use some kind of flag at the top of the file, e.g. `# enable_experimental: nargs` or even similarly to how python works `require 'experimental/nargs'`.

That would make it too easy to use features which are likely to change in production code.
We should avoid production code to use experimental features, especially the ones likely to change significantly.
Otherwise, we can't change experimental features, and they would no longer be "experimental" IMHO.

> Point 2 is more complex. Adopting a standard process would allow us to try to agree on terms/timeframes for "experimental" features. It would ensure all details, ideas and thoughts were contained in one place and maybe alleviate some of the issues that have been raised here.

I think a formal process is out of scope of this issue, although the discussion here might result in some decisions on how to introduce experimental features or to better listen to the community feedback.
It's been tried and failed many times to have a formal process for Ruby, and I think this is a probably a dead-end, we need to evolve the current process step by step.
So I prefer to propose a technical solution here to help addressing the problems I reported, and hear what people propose to address the problems raised above.

> For features which affect the public interface, i.e. adding new methods, syntax, etc, it also provides a standard way to document the implementation so that JRuby, TruffleRuby can implement it too.

That's a separate issue, but indeed good documentation and tests/specs make it definitely easier for other implementations to be compatible, and for users to understand precisely the new features.
I wish I had the time to write an issue about that and motivate committers to better document and test new features.

> I believe Matz has a strong vision, and I think that's good thing. I'm not sure design by (large) consensus works for programming languages.

I don't think we can get everyone to agree anyway.
But, I believe decisions by @matz should consider the feedback from the community.
In the case of these 2 features, I think the community feedback was not considered before introduction, which is frustrating for the community.

> However, maybe slower and more predictable evolution is what people are after. They want to see the proposal and process, and have the appropriate time to give their feedback. Putting it behind experimental flag shows the intention to solicit discussion. It's better to allow people to slowly warm up to the feature, otherwise they get burnt and push back with a lot of force. It's less about the technical issue and more about managing the expectations and needs of the community.

Yes, I think this is very important to address, and the main problem I highlight here.
I think the flag can be a useful way to help addressing that.


----------------------------------------
Feature #15966: Introducing experimental features behind a flag, disabled by default
https://bugs.ruby-lang.org/issues/15966#change-79028

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.7
----------------------------------------
I feel frustrated with some recent experimental features being added in `trunk`. These features, in my opinion:
* did not have enough discussion before being introduced.
* are going to be almost impossible to remove or even improve.
* got criticisms from hundreds of Rubyists in a couple days, illustrating the feature has major issues.

I think some (or maybe all?) experimental features being added to the language should be disabled by default, and enabled by a flag.
For instance, we could use the features system and have `--enable-experimental=...`.

For instance I'm thinking to 2 experimental features which have many problems reported by many people:
* #4475 / #15723 / #15897 Numbered parameters (`@1`, `@2`, ...)
  I think nobody realized matz would say "yes" after 1 month on https://bugs.ruby-lang.org/issues/4475#note-14, and so there was *zero* discussion about `@1`, `@2` before it was merged, and now we might get stuck with it.
  Many people shared their opinions after, and I think we should consider them carefully, which means not releasing `@1`, `@2` "accidentally" in 2.7.

* #15799 The pipeline operator (`|>`).
  Very little discussion before it was introduced also (the bug was only opened 2 weeks).
  The discussion on the bug tracker seems to have been mostly ignored, the feature was added without a response to concerns on the bug tracker.

Even though both these feature are documented as experimental, if they are released in 2.7, they will not be experimental in any way: there is no warning, nothing special to use it.
So there is no hope to change them if they get in Ruby 2.7.

With the new flag, these experimental features would then be disabled by default, until the core team decides they are stable enough (e.g., there are no major issues with it anymore),
and could still be tried as soon as implemented using e.g., `--enable-experimental=nbargs,pipeline`.

This would allow experimenting with the feature, and discuss about it,
and yet not having the feature set in stone and still be able to change it or remove it.

When such a feature is introduced in Ruby, there is very little chance for it to change or be removed.
In fact, it requires many people in the community to  invest significant time to express the problems of the feature and yet sometimes it's not enough.
If by December, no agreement was reached or no decision by matz was taken, the feature will stay (basically forever) whether it's good or has many issues.
This is not a good process. It requires massive efforts from many people in the community and might result in nothing changed.

By massive efforts from many people, I mean for example:
* Going to Japan in person to discuss with Japanese MRI committers and get a better idea of motivations, thoughts, concerns.
  MRI committers outside Japan and Rubyists in general cannot attend or express their opinion at developer meetings where many decisions are taken, and so have to rely on Japanese MRI committers to relay their opinions.

* Summarizing threads of 100+ comments, and preparing slides or a summary for discussion at a developer meeting (it takes hours).
* Trying to get the motivation for the feature written down on the issue tracker, since often it is not well explained on the issue tracker.
* Writing blog posts sharing thoughts and how to improve the feature/why it should be removed.
* Posting comments on the MRI bug tracker (inconvenient for many people, requires extra account, we see more responses on Twitter or GitHub).
* Writing [blog posts](http://katafrakt.me/2019/06/15/im-worried-about-ruby-future/) or issues like this one to express the general problems of the process for introducing experimental features.

Also, people sometimes respond rather aggressively (me too, I am sorry about that),
because I think people feel it's already too late to share opinions and have an impact on the decision,
the feature might have many problems and yet it's extremely unlikely to change.
I can say it's not a comfortable situation at least, I feel ignored, watching things go wrong and not being able to do much about it.

So I propose `--enable-experimental=...` to make the introduction of experimental features more smooth and allow discussion before the feature is basically written in stone.
What do you think?



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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>