Issue #16275 has been updated by zverok (Victor Shepelev).


OK, with several core team members agreeing on this (and even PR prepared), I believe this is already a lost cause, but I'd still like to put some perspective here, if just for reference and future discussion.

> Disclaimer: This matters are somewhat personal for me, I was between the people pushing for "method reference operator", and one of the tickets @naruse references from the phrase "It causes another feature requests ..." is written by me (and another one is pretty close to one of my recent tickets: #16264). Despite this, I am trying to the best of my judging to focus on Ruby's consistency, evolution, and prosperity, not "I want them to merge *my* tickets!" stance.

So...

1. The idea that "the new feature causes people to think of new feature requests" is a **bad** thing, seems a bit unusual. It seemed to me that this is how the *good* design happens: we investigate where current language's syntax and semantic leads us, what new ideas emerge, and what *upcoming* ideas those new ideas produce. So, "this feature leads to thinking about new ways of language usage" seemed a sign of "something right".
2. Ruby's design process is known to be opaque (unevenly split between public discussions, closed meetings, and some particular person-in-charge decisions), but till this moment, I had an unfortunate belief at least part of it happens in this tracker. Probably, this is a false belief.
3. For example, following this belief, I am creating probably an awful lot of proposals, expecting to not only receive "accepted"/"rejected", but clarify understanding of what is in line with language's goals and intuitions. For more particular example, here: #16264 I am not only proposing some new syntax/class, which could be good or bad, but also trying to state some general design ideas, which seem to me *generally applicable*, and have a (slight already) hope to discuss them with core teamˇ˝because I don't know any other place to do so.
4. That's why the claim of "not having the whole picture" was a big surprise: previously, I hoped that *discussions in this tracker* is the way of formulating the "whole picture", and, even more bold, that what's forming with new method reference operator **is**, in fact, a part of clearly visible picture of "gradually yet consistently moving towards functional Ruby". Now, it is a mystery to me whose right and responsibility is to own "the whole picture": is it a closed group of dev. meeting attendants? Matz's very own? Some dedicated "design manager of upcoming functional features"?
5. Another big surprise here is how unanimous the aversion for the new operator seems to be. On the previous iteration (when it was about to be introduced) it seemed to me that everybody agrees that it is an obvious and useful thing (method references as a first-class construct), and the only stumbling block is which characters to use for it, with `.:` being a reasonable compromise. But now a lot of people are suddenly against it (and, the funniest thing is, all for different reasons: "ad-hoc", "don't like how it looks", "numbered parameters is better"), with "method references" believed to, I don't know, esotheric and useless concept?
6. About numbered paramaters: I know it sounds bold, but I do believe it is the most useless new feature syntax-wise for several latest releases. My justification is exactly symmetrical with @naruse's: this is an "orphan" feature, which is "just nice shortcut", but it doesn't lead to any new ideas, any new possibilities, and increases language's syntax surface without increasing language's power. I believe the feature increases the language's power when it encourages new thinking. This way, method reference encourages clearer APIs suitable for passing arguments that belong to API, e.g. redesigning `map { |x| MyService.method(x, lot, of, options) }` into `map(&configured_service.:method)`, thinking when and how we pass `lot, of, options`; while numbered parameters allow preserving *exactly* the same thinking as before, just spare some keystrokes with `map { MyService.method(_1, lot, of, options) }`
7. I understand there are generally two camps when we talk about language design: one that feels current design is more or less "final", just implementation can be improved (but maybe some small "shortcuts" are allowed); and one that feels that language is a living thing, and constantly picking existing concepts to understand what new ideas they can lead to is necessary. Obviously, numbered parameters belong to "first camp thinking", and method references to the second. It is sad that the core team currently tend to stay in the first camp, yet completely understandable.
8. With this being said, I am grateful to this situation: at least, it allowed me to seriously reconsider my involvement with the language and its future.

----------------------------------------
Feature #16275: Revert `.:` syntax
https://bugs.ruby-lang.org/issues/16275#change-82323

* Author: naruse (Yui NARUSE)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
`obj.:method` is introduced at r66667 by #12125 and #13581.
It encourages the functional programming style in Ruby.

But this shorthand syntax is just for methods of `self` without arguments.
It causes another feature requests like #16273 (and lambda compositions like #15428).

Such features will introduce a new view of Ruby but no one illustrates the whole picture yet.
I worried about such patch work may cause a conflict with future expansion of functional programing style or a just a garbage feature.

`.:` syntax is introduced in 2.7.0 preview1, not released in production yet.
How about reverting at this time and re-introduce with a big picture.



-- 
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>