On Friday, 2 August 2013 at 02:21:25 UTC, Maxim Fomin wrote:
> On Thursday, 1 August 2013 at 21:56:46 UTC, John Colvin wrote:
>>
>> You are asking for an "int" to be be implicitly convertable to an "A", which isn't possible.
>
> http://dpaste.dzfl.pl/c3cce6e2
>
> import std.stdio;
>
>
> class A
> {
>     double x;
>     @property double X() { writeln("From A.Get"); return x; }
>     @property double X(double v) { writeln("From A.Set"); x = v; return x; }
>     alias X this;
> 	this(double val) { this.x = val; }
> }
>
> class B
> {
> 	A a;
>     A Y() { writeln("From B.Get"); return a; }
>     A Y(A v ...) { writeln("From B.Set"); a =  v; return a; }
>
> 	this() { a = new A(0); }
> }
>
>
> void main()
> {
> 	B b = new B();
> 	writeln(b.Y);
> 	b.Y = 3;
> 	writeln(b.Y);
>
> 	readln();
> }

Ok... It doesn't work for structs though which is strange. The docs do only mention classes however.

That's not really an implicit conversion, it's an implicit contstruction. It's definitely not like alias this. (In your example the alias this is completely unused)

Does this have any bearing on the wider question? The variadic class construction syntax could be allowed for properties, with a restriction to only one argument passed.

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.

On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:
> 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 the first case other modules can create a mutable pointer to the field x. In the second case other modules cannot create any pointer to field _x.