On Saturday, April 14, 2012 20:47:20 Piotr Szturmaj wrote: > I have following code: > > import std.array, std.range, std.stdio; > > struct CommonInputRange(E) > { > @property bool delegate() empty; > @property E delegate() front; > void delegate() popFront; > } > > void main(string[] args) > { > alias CommonInputRange!dchar DCRange; > static assert(isInputRange!DCRange); > DCRange dc; > auto dcr = "abcdefg"; > auto t = dcr.takeExactly(3); > dc.empty = &t.empty; > dc.front = &t.front; > dc.popFront = &t.popFront; > > for ( ; !dc.empty(); dc.popFront()) > writeln(dc.front()); > } > > As you can see in the for loop, range primitives must be called using > parens (), otherwise they don't work. > > Do you know if there are plans to implement @property for delegates and > function pointers?
front returns an element in the range. In your case, it's returning a delegate, because you have a range of delegates. If front returned a class or struct with a member function called foo, which you wanted to call, then you'd be doing something like for(; !dc.empty; dc.popFront()) writeln(dc.front.foo()); But in your case, it's a delegate, so operating on that delegate means calling it, which means using the parens. dc.front just gives you the delegate, and it would be horrible if it did anything else. If front also called the delegate, the doing something like auto arr = arr(dc); would call each and every one of the delegates in the range, because it uses front to access the element _without calling it_. If there were some way to indicate that a delegate was called with property syntax, then you could no longer distinguish between simply returning the delegate and returning and call it. Not to mention, properties are supposed to be an abstraction that mimicks member variables. That makes no sense whatsoever with a delegate. And in this case, the member variable which _is_ being mimicked (front) happens to be a delegate. So, it makes perfect sense that you'd have to use parens on it to actually call it. - Jonathan M Davis