Restrict Class Properties?

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Thu Feb 22 09:41:20 PST 2007


Manfred Nowak wrote:
> Jarrett Billingsley wrote
> 
>>> What are 'real properties'?
>> True properties would be understood by the compiler as a distinct
>> construct, rather than a hackish rewrite of assignment into a
>> call.
> 
> But what are the benefits of "distinct constructs" in terms of provable 
> correctness? Btw. using the assignment symbol as an alternative for a 
> call seems very canonical to me.

Yes, it's quite normal for an assignment to a property to actually be a 
function call.
It's *not* normal for an assignment to a _function_ to call said function...

Some functions simply weren't meant to be properties.

[snip]
>> the abolishment of the '&' when getting the address of a function
>> or delegate.
> 
> I don't understand that. Would you please elaborate on that?

---
import std.stdio;

int foo() {
     writefln("foo() called");
     return 0;
}

void main() {
     auto x = foo;
     writefln("x: ", typeid(typeof(x)));
     auto y = &foo;
     writefln("y: ", typeid(typeof(y)));
}
---

Output:
---
foo() called
x: int
y: int()*
---

So currently the line declaring & initializing x calls 'foo' and uses 
the return type as value, instead of x becoming a function pointer and 
assigning a pointer to 'foo' as its value. To get the function pointer 
you need to add an '&', like with y.
If 'foo' was not implicitly a property, the language could be changed so 
that the extra '&' would no longer be necessary. There would only be one 
possible value for 'foo' to evaluate to: a pointer to the function.



More information about the Digitalmars-d mailing list