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.
