byKey and byValue: properties or methods?

[torhu]

On 19.01.2012 18:21, torhu wrote:
> On 19.01.2012 18:19, torhu wrote:
>>  On 17.01.2012 07:48, Andrei Alexandrescu wrote:
>>>   I hate I must ask this:
>>>
>>>   int[string] aa;
>>>   foreach (k; aa.byKey) { ... }
>>>
>>>   or
>>>
>>>   int[string] aa;
>>>   foreach (k; aa.byKey()) { ... }
>>>
>>
>>  For it to be a property, I think you should be able to simplify this
>>  example:
>>
>>  ---
>>  auto k = aa.byKey;
>>  writeln(k.front);
>>  k.popFront();
>>  writeln(k.front);
>>  ---
>>
>>  to this:
>>
>>  ---
>>  writeln(k.byKey.front);
>>  k.byKey.popFront();
>>  writeln(k.byKey.front);
>>  ---
>>
>>  and get the same result.  But my understanding is that you wouldn't, in
>>  which case byKey doesn't sense to me as a property.  It creates and
>>  returns a new range object each time you call it, right?
>
> Sorry, I meant this for the second example:
>
> ---
> writeln(aa.byKey.front);
> aa.byKey.popFront();
> writeln(aa.byKey.front);
> ---

The reason would be that if it looks like field access, it should behave 
like that.  People will quickly learn how this works, like they have 
gotten used to .dup and similar, but what happens when third-party 
libraries start doing it too?  It think this is not a good precedence to 
set.  We already have fields and functions, this would be a third kind, 
one that looks like a field but behaves more like a function.