[ruby-core:46875] [ruby-trunk - Feature #6808] Implicit index for enumerations

Issue #6808 has been updated by drbrain (Eric Hodel).


What about the overhead for an infinite enumerator that does not use the implicit index? Especially after a few days of CPU time for a frequently-used enumerator?
----------------------------------------
Feature #6808: Implicit index for enumerations
https://bugs.ruby-lang.org/issues/6808#change-28550

Author: trans (Thomas Sawyer)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0


=begin
One of the less lovely things about Ruby's otherwise elegant enumerables is the lack of ubiquitous access to the current index. Because of this, we end up with a bevy of extra methods that are little more than counter parts and compensation for other enumerable methods to gain access to the index. Examples include, #each_with_index, #each_index and (in many extension libraries) #collect_with_index. It is all rather wasteful, inelegant, and limiting. Heaven forbid we need a #select_with_index, or some other uncommon case.

No doubt this has had some discussion long in the past, but I would like revisit and offer a bnew more concrete proposal...

Thanks to Enumerator, we can now at least do:

  [:a,:b,:c].each_with_index.map{ |e, i| [i, e] }

That's great, but it has obvious shortcomings. It's long winded and it has the overhead of an Enumerator object. Ideally we would want to do this instead:

  [:a,:b,:c].map{ |e| [$i, e] }

Where $i is the implicit index. Now a global variable is surely the simplest solution. But, I can understand that some might object to the use of a global variable, despite the fact that this approach is common with regexp matches like $1, $2, etc. In that case, we could designate a new keyword. Lets call it `index`. 

  [:a,:b,:c].map{ |e| [index, e] }

We might suffer a conflict here however if someone has already used "index" as a block argument. In that case we would need Ruby to allow it to be overridden, in the same sense that one can define a public method called `class`, even though `class` is a keyword in other contexts. 

If this were all that we gained then I say it is a victory, but I'd like to consider also that we go a step further, and instead of having just "index", we have an iterative object. After all Ruby is an OOPL. In this case, the keyword would be `it` and we could do:

  [:a,:b,:c].map{ |e| [it.index, e] }

The nice thing about `it` is that it can have a few other useful methods to improve readability of code, such as `it.first?` and `it.last?` (if size is known for the enumerable). I think this is awesome solution that grants the most readability and flexibility to the language. 

Of course, having an iteration object might bring up concerns about performance, since it will add overhead to create a new iteration instance with every pass. This can be addressed by having the object be mutable, so all that needs to change is the index in the same object. A minor downside here, an `it` can't be stored by reference between passes (e.g. `prev_it = it`), but knowing this, #dup could be used if that was really necessary. If that isn't good enough to curb performance concerns, I would suggest a means of indicating the `it` object be made available. We don't want to drag Enumerator into this so `map.it{...}` is not the solution, but perhaps Ruby could recognize `;it` at the end of block arguments?

  [:a,:b,:c].map{ |e; it| [it.index, e] }

Maybe that syntax can't work, but surely something along these lines could. Personally, I doubt the overhead of mutable `it` is too much, but just in case.

To summarize, I propose an implicit mutable iteration object called `it` that allows access to the enumerations index, plus convenience methods for querying the index. Or, if that is considered too much, then at least an implicit index, either as a global variable or a special keyword. Any of these choices would be a marked improvement, allowing us to avoid the endless proliferation of `_with_index` methods.
=end



-- 
http://bugs.ruby-lang.org/