[#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:66261] [ruby-trunk - Feature #10506] Imprve Enumerator.any? behavior
From:
ruby-core@...
Date:
2014-11-13 14:21:59 UTC
List:
ruby-core #66261
Issue #10506 has been updated by Marc-Andre Lafortune.
Category set to core
Assignee set to Yukihiro Matsumoto
Target version set to Next Major
It probably should have returned an enumerator, but that wasn't as systematic then.
The problem with your proposal is breaking compatibility. I'm quite certain this will be rejected, but I'll let Matz do it.
In the meantime, know that it is easy to get what you want in most cases.
For example:
[].each_with_index.any?{ |obj, index| }
You can also use `to_enum` to get what you want:
[].to_enum(:any?).with_index{ |obj, index| }
----------------------------------------
Feature #10506: Imprve Enumerator.any? behavior
https://bugs.ruby-lang.org/issues/10506#change-49938
* Author: Thomas Sevestre
* Status: Open
* 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/