Anonymous structs

[Era Scarecrow]

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.

   auto point2 = {color: 0x00ff00}; //second definition probably
   point2 = point; //converts how? May be safe..
   point = point2; //loss of data...

>> We can instantiate structs with fewer arguments than elements 
>> they hold. It would either have to go the safe route, or try 
>> it's best to either be 'safe' or 'whatever seems to work' 
>> until you change something and break it utterly with no 
>> description of 'what' it is.
>
> It's not the actual type that's interesting, as long as the 
> members match they're considered to be the same type.

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

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

   /*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
   assert(something2.y == ["some","thing"]); //probably

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

   //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);

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