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