On Mon, 28 Jun 2010 22:40:06 -0400, dsimcha <dsim...@yahoo.com> wrote:
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?
Require it. Otherwise, we are left with the same situation as before. We
already had optional parentheses for properties, and it was/is an
ambiguity disaster. It's the whole reason for introducing @property in
the first place.
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?
If I'm reading this correctly, you are saying that you want &foo.front to
return a pointer to uint, not a delegate?
This is what I'd expect if @property forced no parentheses. That is,
foo.front can be replaced with (foo.front()) always, so &foo.front always
translates to &(foo.front()).
What this means is that you can't get a delegate to the property
function. This makes sense -- if you replaced the property with an actual
field, you wouldn't be able to get a delegate anyways. A property should
operate just like a field.
-Steve
