Anonymous structs

[Jacob Carlborg]

On 2013-02-12 13:08, Era Scarecrow wrote:
> On Tuesday, 12 February 2013 at 07:46:31 UTC, Jacob Carlborg wrote:
>> On 2013-02-11 23:20, Era Scarecrow wrote:
>>
>>>  What if there's another anonymous struct that has a little more?
>>>
>>>   { int x, int y } point = { y: 4, x: 5 };
>>>   { int x, int y, int color } color_point
>>>           = { y: 4, x: 5, color: 0x000000 };
>>>   //which anonymous struct does it go with?
>>>   //Or can auto only work with named/returned structs?
>>>   auto point2 = { x: 1, y: 2 };
>>>
>>>   point = point2; //error, point2 type void _error
>>
>> "point2" is completely independent of the other declarations. But you
>> can think of it having the same type as "point". It can also be
>> implicitly converted to "color_point". It's not the actual type that's
>> interesting, it's the members. The compiler checks the members to see
>> if two values are of the same types.
>
>   Maybe if it was an interpreted language or scripting, but not
> statically typed. Just because they are anonymous doesn't mean they
> suddenly have new 'alias this' members written to convert from one type
> to the other.

You don't seem to get how I want it to work.

>    auto point2 = {color: 0x00ff00}; //second definition probably

This has nothing to do with some other struct. It's lowered to something 
like:

struct __AnonymousStruct_int_color { int color; }
point2.color = 0x00ff00;

It has nothing to do with "color_point".

>    point2 = point; //converts how? May be safe..

Since "point" is declared as:

{ int x, int y } point;

And "point2" is declared as:

{ int color } point2;

It's a type error, the members doesn't match.

>    point = point2; //loss of data...

Same as above.

>   Really? Wow... Sounds like an interface...

Yes, in a way.

>   So this means it would auto deduce it's type based on matching...

When "auto" is used it doesn't try to match on anything else.

>    /*each struct could be a lot more complex, but so long as 'x' is
> present and assignable, then the lower ones allow it to be potentially
> correct */
>    struct S{int x; enum y = 0;}
>    struct T{int x; enum y = "str";}
>    struct U{int x; enum y = 0.45;}
>    struct V{int x; enum y = [1, 2];}
>    {int x; enum junk = false;} something = {};
>    {int x; enum junk = ["some","thing"];} something2 = {};
>
>    assert(something.y == false); //probably

Type error. "something" doesn't have the member "y".

>    assert(something2.y == ["some","thing"]); //probably

Same as above.

>    auto x  = {};      //legally could be S, T, U or V, or anonymous(s)

No, it has nothing to do with any other declared struct. Don't even now 
if this would be legal, since it's kind of pointless do have an 
anonymous struct without members.

>    auto x3 = {45};    //legally could be S, T, U or V, or anonymous(s)

No, same as above.

>    auto x2 = {x: 45}; //legally could be S, T, U or V, or anonymous(s)

Legal, is and can only be anonymous. It has nothing to do with S, T, U 
or V. It's anonymous, period.

>    //may or may not work, 1 in 6 as correct.
>    //if these must be true, then they are all S (or annonymous1)
>    assert(x.y == 0);
>    assert(x2.y == 0);
>    assert(x3.y == 0);

Compile error for all, since none have the member "y".

>   No, deducing types like this won't work for static typing, be they
> anonymous or not. The only way they'd work is if they only existed for
> the one instance, being point or point_color, but auto wouldn't allow
> you to auto determine it; But still that doesn't seem like a good syntax
> to have and I'd rather take the extra line to define the type to ensure
> it's uniqe, Or tuples if it's only data..

You obviously don't understand how I want it to work.

-- 
/Jacob Carlborg