Issue #16275 has been updated by jeremyevans0 (Jeremy Evans).


timriley (Tim Riley) wrote:
> I°«m opposed to this reversion. I was looking forward to using `.:` in 2.7. I felt I should say this as a representative of perhaps a °»silent majority°… of Ruby users. 

If you think your opinion represents the "silent majority" of Ruby users, I think you are operating in an echo chamber.  I realize the this feature may fit nicely into the dry-rb projects, but you should realize that users of dry-rb are probably not representative of the average Ruby user. I don't want to pick on you personally, but please do not pretend to speak for the majority of Ruby users.

> I think that some of the additional ideas this feature was spawning (i.e. some of the other tickets referenced above) were potentially very helpful evolutions of the language. 

Most Ruby users I have spoken too (maybe even a "silent majority" of Ruby users :) ) feel that the introductions of similar features such as `Proc#<<` and `Proc#>>` actually make the resulting code harder to read.  What is considered a helpful evolution by some users can be cryptic and harder to understand for others.

All additional syntax has costs in terms of both internal/implementation and external/cognitive complexity.  All proposals to add syntax need to consider the costs of adding the syntax, and the expected benefits of the syntax.

Regarding the tickets referenced above:

#16264: This complicates things further, and I am guessing that most Ruby users would find this approach to structuring more difficult to understand than traditional Ruby.  Do you think most Ruby users would prefer:

```ruby
paragraph_hashes.map(&.:merge.with(author: current_author))
filenames.map(&File.:read.with(mode: 'rb'))
```

to:

```ruby
paragraph_hashes.map{|h| h.merge(author: current_author)}
filenames.map{|f| File.read(f, mode: 'rb')}
```

I guess if you really hate naming block variables, and you really hate numbered parameters, maybe the former is preferable. :)

#14145: While `self.:method_name` instead of `method(:method_name)` is a bit shorter, that doesn't seem like a major reason to add special syntax, considering `inspect` is mainly used for debugging. Also, this was already committed, so the loss of `.:` will not affect it.

> Regarding the point that a feature like `.:` should wait until it comes out as part of a °»whole picture,°… how is that meant to happen when contributors like zverok do not have access to various key aspects of the development and decision-making process, as he has questioned in his comment? Would the Ruby core team really be accepting of a whole family of multiple related features coming into a release all at once? That feels unlikely to me, especially given zverok and the other key drivers of these ideas do not have access to some of the avenues for development discussion outside of this bug tracker. So their best bet is to introduce the smaller features one by one - the initial parts of the °»whole family°… a which is what they°«ve done with `.:`.

I don't think we should reject this because we don't have the "whole picture".  I think we should reject this because the reason it was added is better served by another feature that is more flexible and easier for the average Ruby user to understand.  Numbered parameters handle both cases where you would use `.:` and cases where you would use the feature proposed in #16264.
 
> So where does this leave this area for improvement to Ruby? If `.:` is rejected now, it feels like it closes off this evolutionary branch of language features for good. Which, imo, is anything but good.

I don't think this closes off anything. This is just a specific feature that is independent of other features.    If there were other features in this "evolutionary branch" that improved Ruby, I think they would certainly be considered.

For example, with #16264, if `.:` was removed, I assume that `paragraph_hashes.map(&.:merge.with(author: current_author))` could still work, and `filenames.map(&File.:read.with(mode: 'rb'))` could be changed to `filenames.map(&File.method(:read).with(mode: 'rb'))`

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

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