---------
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?

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.

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.

>
> 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.

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

>
> 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.