• Carl Sturtivant (23/23) Nov 30 2013 The following is boiled down from a real world context. I'm using
• Carl Sturtivant (3/3) Nov 30 2013 I just confirmed the same behavior on Ubuntu amd64. dmd 2.063.2
• Kenji Hara (22/25) Dec 01 2013 This is intended behavior change from 2.064.
• Carl Sturtivant (1/5) Dec 03 2013 Interesting, useful, and a surprise. Thank you!
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/26) Dec 01 2013 At least the discrepancy warrants a bug report:

"Carl Sturtivant" <sturtivant gmail.com> writes:

The following is boiled down from a real world context. I'm using 
dmd 2.064.2 Windows. Can someone please explain what's going on.

================

struct my_integer {
     int val = 99;
     alias val this;
     //this( int n) { val = n; }
}

struct blah {
     my_integer Integer;

     this( int n) { Integer = n; }
     ref blah opAssign( int n) { Integer = n; return this; }
}

================

The constructor in blah does not compile unless the constructor 
in my_integer is uncommented. Yet the opAssign function in blah 
compiles just fine.

The error message is
  Error: cannot implicitly convert expression (n) of type int to 
my_integer
and the line causing it is blah's constructor.

This behavior did not exist with dmd 2.063.2 (Windows) --- I 
reverted to check this.

"Carl Sturtivant" <sturtivant gmail.com> writes:

I just confirmed the same behavior on Ubuntu amd64. dmd 2.063.2 
compiles the example and dmd 2.064.2 produces the same error as 
the Windows 32 bit version.

"Kenji Hara" <k.hara.pg gmail.com> writes:

On Saturday, 30 November 2013 at 22:28:14 UTC, Carl Sturtivant 
wrote:
 I just confirmed the same behavior on Ubuntu amd64. dmd 2.063.2 
 compiles the example and dmd 2.064.2 produces the same error as 
 the Windows 32 bit version.

This is intended behavior change from 2.064.

http://dlang.org/class#field-init

struct my_integer {
     int val = 99;
     alias val this;
}
void test() {
   //my_interger num = 1;  // NG
     my_interger num = my_interger(1);  // OK
     // 'alias this' has no effect for object initialization
}
struct blah {
     my_integer num;

     this(int n) {
       //num = n;  // also NG, my_integer cannot *initialize* by 
int value
         num = my_interger(n);  // OK
     }
}

Kenji Hara

"Carl Sturtivant" <sturtivant gmail.com> writes:

 This is intended behavior change from 2.064.

 http://dlang.org/class#field-init
 [...]
 Kenji Hara

Interesting, useful, and a surprise. Thank you!

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 11/30/2013 02:18 PM, Carl Sturtivant wrote:
 The following is boiled down from a real world context. I'm using dmd
 2.064.2 Windows. Can someone please explain what's going on.

 ================

 struct my_integer {
      int val = 99;
      alias val this;
      //this( int n) { val = n; }
 }

 struct blah {
      my_integer Integer;

      this( int n) { Integer = n; }
      ref blah opAssign( int n) { Integer = n; return this; }
 }

 ================

 The constructor in blah does not compile unless the constructor in
 my_integer is uncommented. Yet the opAssign function in blah compiles
 just fine.

 The error message is
   Error: cannot implicitly convert expression (n) of type int to my_integer
 and the line causing it is blah's constructor.

 This behavior did not exist with dmd 2.063.2 (Windows) --- I reverted to
 check this.

At least the discrepancy warrants a bug report:

   https://d.puremagic.com/issues/

Ali