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


Some more thoughts on a similar subject by the author of RuboCop in a blog post:
https://metaredux.com/posts/2019/12/06/ruby-where-do-we-go-now.html

There are interesting discussions in the Reddit of that blog post:
https://www.reddit.com/r/ruby/comments/e6ye3t/ruby_where_do_we_go_now/

I'll cite here part of my reply on Reddit (but please take a look at other replies there):

Although the post is indeed a bit of a rant (I'm not blaming, I'm not sure what's a good way to be heard by the core team or matz), I do agree with many frustrations expressed there.

I was also disappointed flip-flops are allowed again, based on just a few comments, even though it's such a niche feature basically only used to select a subset of contiguous lines with hidden state. How often does one need that?

For Numbered Parameters and for the Pipeline Operator I actually spent dozens of hours fighting these features, because it was clear to me those were completely wrong for Ruby. I'm happy the end result is the Pipeline Operator was removed and we got a nicer syntax for Numbered Parameters. But I feel way too much time was invested by many people before those changes landed. And I simply don't have that much time to invest in the hope that something might or not change.

To get an idea, in the hope to be heard on those features:
* I argued with 20 comments (total: 129 comments) on https://bugs.ruby-lang.org/issues/15723
* I filed https://bugs.ruby-lang.org/issues/15966 and https://bugs.ruby-lang.org/issues/15752 to try to actually mark "experimental features" properly and make them disabled by default/under a clear namespace. Not much came out of that so far, except matz agreed to set up the rule to remove half-baked features before the release.
* I argued on https://bugs.ruby-lang.org/issues/15708 and filed https://bugs.ruby-lang.org/issues/16178 which I believe was a critical flaw in the design of numbered parameters (my opinion obviously), and yet it took a lot of efforts to be heard. I even presented that case at a developers meeting in Japan before RubyKaigi 2019, and yet nothing moved then. I had to expose it under a dozen different angles and finally one of them convinced matz (the fact that Enumerable#map doesn't work with _1 was not enough somehow!). I'm puzzled how such a thing like { _1 } != { |x| x } could last so long to be resolved.

I'm not sure what's a good way to be heard by matz and the Japanese Ruby core team honestly. It seems most decisions are taken during the developers meetings in Japan, only attended by people living in Japan. I'm sure some of them read comments on the bug tracker, but I guess matz listens more easily to people there than to comments on the bug tracker (not criticizing, obviously easier because of language barrier, being able to interact real-time, etc). I expressed some of that in https://bugs.ruby-lang.org/issues/15966.

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

* Author: Eregon (Benoit Daloze)
* Status: Rejected
* 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>