On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:
On Friday, 2 August 2013 at 01:46:28 UTC, Jesse Phillips wrote:
I'm going to provide a reduced case for the issue you are
having.
struct Foo {
double x;
alias x this;
}
void main() {
Foo a;
a = 8; // Alias this assignment
assert(a.x == 8);
fun(7); // What you want
}
void fun(Foo a) {
}
You're claiming that since Foo is requested to "be" a double
calling fun(7) should just assign 7 to x.
What you're missing is that it is Foo which behaves like
double, however fun(7) there is no Foo involved, it doesn't
exist. You're actually requesting that a Foo is created, then
to have an assignment of 7 to x of the new temporary Foo.
This is not a bug, it is by design. Alias this is sugar of
type it is declared in not the type it is declared to.
Um, but I'm not talking about a free function or member
function but a property... they are suppose to be special else
whats the point. They are suppose to wrap fields.
Because of this "design" you speak of, I can't use a double
wrapped(essentially) type because it is in an interface and I
can't use a field in the interface.
What is the difference between
class A
{
int x;
}
class A
{
private int _x;
@property int x() { }
@property int x(int v) { }
}
? From the outside world there is suppose to be no difference.
In an ideal world, perhaps. There has been a huge amount of
discussion about properties here before and no solution is
perfect.
