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
