Misc #17399: Are endless methods experimental?

• Status: Closed
• Assignee: -

[zverok (Victor Shepelev)]

They are marked as such in NEWS, but an attempt to define one doesn't produce a warning (unlike other features marked this way, like one-line pattern-matching or find patterns)

[Eregon (Benoit Daloze)]

I think a warning would better, especially since there were quite a few changes regarding what was accepted after the =.

Also, they purely seem redundant to me and I guess to others, so maybe they might be removed one day like the pipeline operator?

We should warn then if either of these is a possibility (either being removed or changing what's accepted after the =).

[matz (Yukihiro Matsumoto)]

I agree with @Eregon (Benoit Daloze). We still need more investigation for issues like #17398

Matz.

[matz (Yukihiro Matsumoto)]

Additional note:

• I am not going to remove endless-def
• I don't think the warning is necessary. Since we are not going to remove it.

Matz.

[Eregon (Benoit Daloze)]

I think the warning would be helpful if we change what is allowed after =, especially if we would forbid something that was previously allowed (e.g., to make the rule clearer).
If there is no warning, people will assume it's a stable feature, while it seems not yet the case, and it will be difficult to do any change without breaking compatibility.

[zverok (Victor Shepelev)]

@matz (Yukihiro Matsumoto) I believe we need a final decision ASAP.

Either the feature is experimental and should warn so (it still does not, as of ruby 3.0.0dev (2020-12-21T09:17:45Z master d84dd66da0)), or the [EXPERIMENTAL] notice should be removed from the NEWS before the final Ruby 3.0.

[mame (Yusuke Endoh)]

Note that there is no consensus that a warning should be printed when any experimental features are used. As far as I understand, the reason why pattern matching prints a warning is just because the author, @ktsj (Kazuki Tsujimoto), is an attentive person. Personally, I'm not always a fan of such a warning because it discourages people to give it a try. I respect the decision of the author, though.

[marcandre (Marc-Andre Lafortune)]

I agree with @mame (Yusuke Endoh). I just "rediscovered" refinements this year 😅

Experimental features are typically new features. One needs to read the doc for new features. Experimental warning best put there.

Have we considered a :experimental warning kind (off by default)?

[zverok (Victor Shepelev)]

@mame (Yusuke Endoh) OK. That's kinda weird for me (that some EXPERIMENTAL features are warned as such, and others aren't), but if this is the official policy, let it be so.

In 3.0, one-line pattern matching is experimental and warns, Ractors are experimental and warn, endless methods are experimental and don't. Let the chaos reign! :)

Have we considered a :experimental warning kind (off by default)?

It is actually there, but is ON by default :)

[1, 2, 3] => [a, *]
# (irb):1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby!
Warning[:experimental] = false
[1, 2, 3] => [a, *]
# => nil 

...though, considering that making experimental feature warn is completely on the conscience of each feature's author, I am not sure why anybody bothered to introduce the category.

[Eregon (Benoit Daloze)]

I once tried to make the point that if something is experimental it needs to warn, otherwise users in practice will consider it stable in #15966, but yes that seems a lost cause...

I guess we can reject based on "experimental sometimes means nothing for ruby-core"?

[shevegen (Robert A. Heiler)]

I guess the discussion here may be more what exactly "experimental" means, similar
to what people expect a "constant" to be (non-changable, but if you come from
the point of view of ruby's philosophy then it makes sense to be able to change
it and not get into the way of the ruby user; similar situation to Filex.exist?
versus File.exists?, where the "correct" answer depends on the point of view).

Even the "experimental it needs to warn" may be context-dependent - a warning
may be super-helpful, but also not so helpful (see the keyword args change
in the past).

I agree with @mame (Yusuke Endoh). I just "rediscovered" refinements this year 😅
Experimental features are typically new features.

Yeah but I think refinements are no longer "experimental" since some time. :)
(Although I'd love some syntax changes ... but I don't want to distract
from this issue here.)

In some ways I can understand zverok and eregon, not necessarily agreeing
with them on the topic, since I think it is also context-dependent on
the feature itself. For a newcomer experimenting with a feature, the
warning may be helpful, whereas for those who already use pattern
matching, they may not need the warning.

But it's late in 2020! 2021 is a new year for new ideas and suggestions -
happy holidays! :D

[mame (Yusuke Endoh)]

"Experimental" means to me "we are a little more flexible against any feedback". We will make reasonable efforts to keep compatibility of any language feature that is once released, even if it is experimental. For example, we will not remove a feature, unless something extremely bad happens. In regard to this ticket, matz said "I am not going to remove endless-def". It is enough to me.

As far as I know, pattern matching is the first case where an experimental warning is printed. It will be non-experimental in 3.0.0. There are some minor changes and bug fixes, but the spec itself looks almost unchanged since 2.7. Honestly, I'm unsure if this approach was a success. I'm afraid if the warning discouraged people to try pattarn matching too strongly. After it shows no warning, people will start trying it, and then real feedbacks may come. I guess maybe we will respond to the feedbacks to reasonable extent, but this will make the meaning of "experimental" more unclear.

[zverok (Victor Shepelev)]

@mame (Yusuke Endoh) My concern is not "we should warn" (or "we shouldn't warn") about experimental features, but about consistency. It seems that since 2.7, when warning categories and first experimental warnings were introduced, it became an ad-hoc rule to match "experimentalness" in docs with the warning.

I am OK with a warning (especially considering it is tunable); I'd be OK with the new decision "warnings were not necessary, actually". What bothers me is inconsistency.

[zverok (Victor Shepelev)]

• Status changed from Open to Closed