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