byKey and byValue: properties or methods?

[Nick Sabalausky]

"Alvaro" <alvaroDotSegura at gmail.com> wrote in message 
news:jf4tr4$lnv$1 at digitalmars.com...
> El 17/01/2012 23:32, Timon Gehr escribió:
>> On 01/17/2012 11:19 PM, Alvaro wrote:
>>> El 17/01/2012 18:24, Andrei Alexandrescu escribió:
>>>>> On 2012-01-17 06:48:26 +0000, Andrei Alexandrescu
>>> ...
>>>>
>>>> aa.keys is taken btw.
>>>>
>>>
>>>
>>> OK, I see, .keys and .values currently return dynamic arrays.
>>>
>>> But the most appropriate property name for the above range should indeed
>>> be .keys !
>>>
>>> Now, wouldn't it be be better to turn .keys into the proposed range?
>>>
>>> Let's see. What is the use of .keys?
>>>
>>> I searched phobos and found that .keys is mostly used to itarate over
>>> the keys in a foreach loop. With the problem that is needs to allocate a
>>> dynamic array. If silently changed to the proposed range, the foreach
>>> loop would do the same and without an allocation.
>>>
>>> In a few unittests, .keys is followed by .sort, usually to print the
>>> keys in order. That would not work... unless the produced range includes
>>> a .sort method. Alternatively a .sortedKeys property can be added.
>>>
>>> The other use I see in phobos is just a typeof(a.keys[0]), which could
>>> be replaced by typeof(a.keys.front)
>>>
>>>
>>> What is the benefit of .keys as a range? it does not allocate an array,
>>> just gives the keys.
>>>
>>> And if an array is needed, it is easy to turn a range into an array.
>>> [Well, I'm missing a more direct way of doing that than using foreach
>>> and appending]
>>>
>>
>> See std.array.array.
>
> Oops. Yes, thanks.
>
> So, not bad. In those [infrequent, I'd say] cases needing an array one 
> would do:
>
>  auto keys = array(aa.keys);
>

My thoughts exactly. The current .keys made sense back in the days before 
ranges, std.algorithm, etc, but not so much anymore. Vote++