www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - implicit conversion to alias this

reply "Tobias Pankrath" <tobias pankrath.net> writes:
---------
struct A { bool a; alias a this; }
struct B { int b; alias b this; }

A a = false; // works
B b = 12; // works

struct C
{
     A aa;
     B ab;
}

C c = { false, 12 }; // does not work, because the implicit 
conversion does not happen.
-----

What is the reason to allow the first two assignments? Isn't it 
just another implicit conversion that shouldn't be allowed?
Jun 25 2012
next sibling parent reply "BLM768" <blm768 gmail.com> writes:
On Monday, 25 June 2012 at 20:06:21 UTC, Tobias Pankrath wrote:

 ---------
 struct A { bool a; alias a this; }
 struct B { int b; alias b this; }

 A a = false; // works
 B b = 12; // works

 struct C
 {
     A aa;
     B ab;
 }

 C c = { false, 12 }; // does not work, because the implicit 
 conversion does not happen.
 -----

 What is the reason to allow the first two assignments? Isn't it 
 just another implicit conversion that shouldn't be allowed?


The compiler isn't "smart" enough to realize that you're trying 
to use an implicit conversion. It's only told to expect the 
conversion in certain situations, such as assignment, and getting 
it to work for rarer cases would involve patching it with more 
special-case code.  The initializer is also expecting struct 
_values_; I don't think that you could call a function that wants 
an A and give it a bool, either. Making a struct value from an 
expression and initializing a struct in a definition are subtly 
different and follow different codepaths in the compiler.
Jun 27 2012
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 28 June 2012 at 04:43:07 UTC, BLM768 wrote:

 On Monday, 25 June 2012 at 20:06:21 UTC, Tobias Pankrath wrote:

 ---------
 struct A { bool a; alias a this; }
 struct B { int b; alias b this; }

 A a = false; // works
 B b = 12; // works

 struct C
 {
    A aa;
    B ab;
 }

 C c = { false, 12 }; // does not work, because the implicit 
 conversion does not happen.
 -----

 What is the reason to allow the first two assignments? Isn't 
 it just another implicit conversion that shouldn't be allowed?


 The compiler isn't "smart" enough to realize that you're trying 
 to use an implicit conversion. It's only told to expect the 
 conversion in certain situations, such as assignment, and 
 getting it to work for rarer cases would involve patching it 
 with more special-case code.  The initializer is also expecting 
 struct _values_; I don't think that you could call a function 
 that wants an A and give it a bool, either. Making a struct 
 value from an expression and initializing a struct in a 
 definition are subtly different and follow different codepaths 
 in the compiler.


I'm fine that the assignment to C is verboten. I'd disallow the 
first assignments to and would like to know, why they are kept.
Jun 27 2012
next sibling parent "BLM768" <blm768 gmail.com> writes:
 I'm fine that the assignment to C is verboten. I'd disallow 
 the 
 first assignments to and would like to know, why they are kept.


OK, now I get it. I'm not sure why they're allowed, either; I 
guess that it's just because it's written with assignment syntax. 
On second thought, it might be for cases where you have a struct 
that, for example, wraps an int to trap overflows. You'd want a 
transparent interface for that; the fact that the initializer for 
C isn't accepted looks like a potential wrinkle in D's design. 
The only reason I can see to restrict the areas in which the 
conversion takes place is to prevent issues with function 
overloading, so the compiler probably should allow your code. 
This might be a good situation for an enhancement request.
Jun 28 2012
prev sibling parent "BLM768" <blm768 gmail.com> writes:
 I'm fine that the assignment to C is verboten. I'd disallow 
 the 
 first assignments to and would like to know, why they are kept.


OK, now I get it. I'm not sure why they're allowed, either; I 
guess that it's just because it's written with assignment syntax. 
On second thought, it might be for cases where you have a struct 
that, for example, wraps an int to trap overflows. You'd want a 
transparent interface for that; the fact that the initializer for 
C isn't accepted looks like a potential wrinkle in D's design. 
The only reason I can see to restrict the areas in which the 
conversion takes place is to prevent issues with function 
overloading, so the compiler probably should allow your code. 
This might be a good situation for an enhancement request.
Jun 28 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, June 25, 2012 22:06:20 Tobias Pankrath wrote:

 ---------
 struct A { bool a; alias a this; }
 struct B { int b; alias b this; }
 
 A a = false; // works
 B b = 12; // works
 
 struct C
 {
 A aa;
 B ab;
 }
 
 C c = { false, 12 }; // does not work, because the implicit
 conversion does not happen.
 -----
 
 What is the reason to allow the first two assignments? Isn't it
 just another implicit conversion that shouldn't be allowed?


They don't compile on the latest master, so I guess that it was a bug in 2.059 
which was fixed.

- Jonathan M Davis
Jun 28 2012