Re: Set#map! vs. map

I agree with those who have said that Set.map should return an array as 
it does now.  And I also agree with those who have indicated that the 
method name Set.map! is not optimal.

Matz's question about whether there should be a general rule is a good 
one, however that bears more consideration.

The rdoc for Enumerable.map says that it returns an array.  If that is 
true, then I believe that all Enumerable classes should honor that 
contract and return arrays.

I want to point out, however, that in Ruby 1.9 it is no longer true, as 
map (and most other iterators) now return an Enumerator when invoked 
with no block.   I gather that Matz is thinking about things like 
iteration over infinite lists for Ruby 2.0 and that Enumerator is the 
first step toward that.  I'd suspect that another requisite step will be 
to change the general rule about iterators like map: instead of 
returning arrays, the most we'll be able to count on is that they return 
an Enumerable object.

I don't propose this as a change for 1.9, but I could see adopting (for 
Ruyb 2.0) a general rule that says that map (and collect) return an 
Enumerable object.  And further, that the enumerable object has the same 
number of elements as the receiver object, and that the returned 
enumerable object iterates the mapped values in the same order that the 
receiver object iterates its values.


Note that this general rules implies that Set.map may not return a Set. 
  Consider:

s = Set.new [1,2,3]
s2 = s.map { |x| 1 }

If map returned a Set, the returned set would have only a single 
element, violating the general rule.

(Currently Set.map! {|x| 1} returns a set with a single element.  My 
intuition is that it should instead raise an error about duplicate 
elements, but then again it does have that exclamation point after it!)

	David Flanagan