On 2/4/13 12:53 AM, kenji hara wrote:
If the expression is generated from string mixin, might have a problem.
// This is much simple case. Real example might be more complicated.
template AddressOf(string exp)
{
enum AddressOf = "&" ~ exp;
}
struct S {
@property int prop() { return 1; }
}
void main() {
S s;
assert(s.prop == 1);
int* p = mixin(AddressOf!("s.prop")); // &s.prop returns delegate
}
I think that parenthesis-dependent syntax is not good.
Kenji Hara
Couldn't AddressOf use "&(" + exp + ")"?
I thought more about this. The problem remains even without @property,
due to optional parens in function invocation. Consider:
ref int fun() { ... }
auto p1 = &fun;
auto p2 = &(fun);
auto p3 = &(fun());
What are the types of the three? The optional parens in invocation
require some disambiguation. I think the sensible disambiguation is to
have &fun take the address of fun and the other two take the address of
fun's result.
I would agree restricting the properties, but requiring a __trait to
take the address of a regular function or method seems overkill.
Andrei
