On Tue, 29 Jun 2010 01:53:05 -0400, Nick Sabalausky <a...@a.a> wrote:
"dsimcha" <dsim...@yahoo.com> wrote in message
news:i0bme6$2ph...@digitalmars.com...
Once enforcement of @property is enabled, we need to decide whether
calling an
@property function using ()s should be legal. In other words, should
@property **require** omission of ()s or just allow it? My vote is for
just
allowing omission, because I've run into the following ambiguity while
debugging std.range. Here's a reduced test case:
struct Foo {
uint num;
@property ref uint front() {
return num;
}
}
void main() {
Foo foo;
uint* bar = &foo.front; // Tries to return a delegate.
}
If I can assume that @property functions can be called with explicit ()s
to
forcibly disambiguate this situation, then I can fix these kinds of bugs
by
simply doing a:
uint* bar = &(foo.front());
Can we finalize the idea that this will continue to be allowed now so
that
I
can fix the relevant bugs in Phobos and know that my fix won't be broken
in a
few compiler releases?
Crazy idea:
The whole point of properties is to simulate a member that's *not* a
function. With that in mind, does it even make sense to allow the use of
unary "&" to get a delegate to a property at all? On the off-chance that
you
really do need a delegate to a setter/getter you can just make a lambda -
and that works exactly the same even if it's a real member variable
instead
of a property. And inlining could take care of any performance issues.
1. You'd get a closure, not a lambda, which generally would require a heap
allocation.
2. The idea's not too crazy, I've been having similar thoughts. However,
3. D's a system's programming language and not being able to get a
function pointer to a function seems wrong.
4. There's actually valid use cases where getting the address of a
property makes sense. One of the intents of properties is to allow a
library to upgrade a variable to a set of methods without breaking third
party user code. And in the new version of your library, taking the
address might make sense or be needed due to new functionality.
Somewhat related question: What normally happens when you try to get a
delegate to an overloaded function?
It grabs the first overload, IIRC.
