[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66262] [ruby-trunk - Feature #10506] [Rejected] Imprve Enumerator.any? behavior
From:
eregontp@...
Date:
2014-11-13 15:26:36 UTC
List:
ruby-core #66262
Issue #10506 has been updated by Benoit Daloze.
Status changed from Open to Rejected
In other words, any? already has behavior when there is no block:
It uses an identity block { |e| e } as said in the documentation.
So it checks if there is any truthy member in the enumerable.
Changing it is unbearable for compatibility, so I close the issue.
Many users already use it for !enum.empty?, although it is not semantically the same.
We would not want to potentially break every use of any? with no block.
If you insist, please propose a nice transition path, but I fear it would take very long to keep some kind of compatibility (first deprecate, then remove, wait a while and add it with new behavior).
----------------------------------------
Feature #10506: Imprve Enumerator.any? behavior
https://bugs.ruby-lang.org/issues/10506#change-49939
* Author: Thomas Sevestre
* Status: Rejected
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: core
* Target version: Next Major
----------------------------------------
IMHO the API `Enumerable.any?` behavior could be improved in the following manner:
any? { |obj| block } → true or false
any? → an_enumerator
This would allow to do things like
[].any?.with_index { |obj, index| }
And it would be more consistent with collect and other Enumerable functions:
collect { |obj| block } → array
collect → an_enumerator
--
https://bugs.ruby-lang.org/