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

Status changed from Closed to Open

Sorry for my arrogance, but I am kinda surprised (to say the least) with how this ticket is treated.

* Ticket is closed silently (are you aware that it is an event when Redmine doesn't send the notification, so unless I'll check manually, I am not aware that ticket is closed?)
* [Developer meeting discussion log](https://docs.google.com/document/u/1/d/1W_wrFsFxxU1MepA6HBpfl-9h-nLD8EBsgMsS7yTDvHE/pub) seems to completely miss the point of the ticket. Quoting from there:

  > **Mame**: Use a block.  You then want syntactic sugar for passing an argument, and then for partial application, blah blah blah.
  > **knu**: We should not add fancy new features around procs and symbols if the real problem is that block syntax is not good enough, like `|x|` is always necessary. (See above for the default block parameter syntax)

I understand that typical problem with my "large" tickets is I am trying to consider too much things (believing it would describe the problem better), and sometimes it is too hard to tell what's my _main_ point. So I should try better.

---

**Main point of this ticket:** Special treatment of `#call` in `Proc#>>` and `Proc#<<` is **inconsistent** with the rest of the language.

There are **two possible solutions** for this problem:

1. **change `#>>` and `#<<` to use `#to_proc`**, or, alternatively
2. **codify that `#call` from now on has a special meaning** in Ruby and probably decide on other APIs that should respect it

This ticket is NOT about "I want to chain symbols, it is nice". What I want is **language consistency**, not **fancy new features**. In fact, I want exactly the opposite as "fancy new features (that ignore consistency)", which current implementation of `#>>`/`#<<` apparently is.

----------------------------------------
Bug #15428: Refactor Proc#>> and #<<
https://bugs.ruby-lang.org/issues/15428#change-76256

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
#6284 introduced `Proc#>>` and `Proc#<<`, but the requirements to the argument is totally inconsistent with ANY other place in Ruby.

Currently, it is the **only** place in Ruby where coercing argument to `Proc` is done with `#call` method. Everywhere else it is done with `#to_proc`, and `#call` method never had any special significance except for `.()` sugar. I believe there are two possible actions:

1. change `#>>` and `#<<` to use `#to_proc` (which will give Symbols composability for free), **or, alternatively**
2. state that `#call` from now on has a special meaning in Ruby and probably decide on other APIs that should respect it (for example, auto-define `#to_proc` on any object that has `#call`)

Either is OK, the current situation is not.

PS: One more problem (that probably should be discussed separately) is that check for `#call` existence is performed pretty late, which can lead to this kind of errors:

```ruby
# At code loading time:

# I erroneously thought this is correct. It is not, but the line would perform without
# any error.
PROCESSOR = JSON.method(:parse) >> :symbolize_keys 

# Later, in runtime:
'{"foo": "bar"}'.then(&PROCESSOR)
# NoMethodError (undefined method `call' for :symbolize_keys:Symbol)
```

**UPD 2018-12-29:** As this ticket was ignored prior to 2.6 release, I rewrote it in an "actionable" instead of "question" manner. 



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