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.
The point of properties is to wrap a type... yet I can't do
that.... and also because A is an interface there is not even a
fallback to the using a field to get it to work.
Anyways, this isn't headed anywhere... It's easy to sit back and
try to analyze the situation without having ran into the problem
directly.
