Feature #6808
closed
Implicit index for enumerations
Description
=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
Updated by 
Updated by 
Updated by 
Updated by Anonymous 
Updated by 
Updated by