www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Two questions about assignments

reply "bearophile" <bearophileHUGS lycos.com> writes:
Do you know if it's OK to accept x3 assignment and refuse the a2 
assignment?


struct Foo {
     immutable(char)[4] bar;
}
Foo x1 = { "AA" };            // No error.
immutable(char)[4] a1 = "AA"; // No error.
void main() {
     Foo x2 = { "AA" };        // No error.
     Foo x3 = Foo("AA");       // No error.
     immutable(char)[4] a2 = "AA"; // Error: lengths don't match
                                   // for array copy, 4 = 2
}

-------------------------

This is a recent change in std.typecons.tuples:

// 
https://github.com/9rnsr/phobos/commit/fdcaba7226c978f281f2d237fc772c6d7913eaf3


But from this test they don't seem to be one a subtype of the 
other:


import std.typecons: Tuple;
void main() {
     alias T1 = Tuple!(int, int);
     alias T2 = Tuple!(int,"x", int,"y");
     auto t1 = T1(10, 20);
     auto t2 = T2(100, 200);
     t1 = t2; // OK.
     t2 = t1; // OK?
}


Bye and thank you,
bearophile
May 27 2013
parent reply "Kenji Hara" <k.hara.pg gmail.com> writes:
On Monday, 27 May 2013 at 18:00:38 UTC, bearophile wrote:

 Do you know if it's OK to accept x3 assignment and refuse the 
 a2 assignment?


 struct Foo {
     immutable(char)[4] bar;
 }
 Foo x1 = { "AA" };            // No error.
 immutable(char)[4] a1 = "AA"; // No error.
 void main() {
     Foo x2 = { "AA" };        // No error.
     Foo x3 = Foo("AA");       // No error.
     immutable(char)[4] a2 = "AA"; // Error: lengths don't match
                                   // for array copy, 4 = 2
 }


This is known static array initializing inconsistency between 
DeclDefs scope and statement scope. I think it is a bug.


 -------------------------

 This is a recent change in std.typecons.tuples:

 // 
 https://github.com/9rnsr/phobos/commit/fdcaba7226c978f281f2d237fc772c6d7913eaf3


 But from this test they don't seem to be one a subtype of the 
 other:


 import std.typecons: Tuple;
 void main() {
     alias T1 = Tuple!(int, int);
     alias T2 = Tuple!(int,"x", int,"y");
     auto t1 = T1(10, 20);
     auto t2 = T2(100, 200);
     t1 = t2; // OK.
     t2 = t1; // OK?
 }


std.typecons.Tuple supports "structural assignment" before the 
change.
The code also works with 2.062.

Kenji Hara
May 27 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kenji Hara:

Thank you very much for your gentle and useful answers :-)



 struct Foo {
    immutable(char)[4] bar;
 }
 Foo x1 = { "AA" };            // No error.
 immutable(char)[4] a1 = "AA"; // No error.
 void main() {
    Foo x2 = { "AA" };        // No error.
    Foo x3 = Foo("AA");       // No error.
    immutable(char)[4] a2 = "AA"; // Error: lengths don't match
                                  // for array copy, 4 = 2
 }


 This is known static array initializing inconsistency between 
 DeclDefs scope and statement scope. I think it is a bug.


I will add it to Bugzilla then, if it's not already there.

(By the way, in my opinion the D compiler should see as bugs all 
those 5 cases, as explained in Issue 3849, because when I specify 
the array length I do it also for safety, to be sure the literal 
gives me exactly that number of chars. This is useful for tables 
and data represented as strings of chars.)






 -------------------------

 This is a recent change in std.typecons.tuples:

 // 
 https://github.com/9rnsr/phobos/commit/fdcaba7226c978f281f2d237fc772c6d7913eaf3


 But from this test they don't seem to be one a subtype of the 
 other:


 import std.typecons: Tuple;
 void main() {
    alias T1 = Tuple!(int, int);
    alias T2 = Tuple!(int,"x", int,"y");
    auto t1 = T1(10, 20);
    auto t2 = T2(100, 200);
    t1 = t2; // OK.
    t2 = t1; // OK?
 }


 std.typecons.Tuple supports "structural assignment" before the 
 change.
 The code also works with 2.062.


I know it's not a regression. But you say:
"Named-field tuple should be a subtype of unnamed-field tuple."

You can have sub-typing, or you can have structural typing, but 
mixing the two "silently" seems a mess.

Also in your test cases of that commit fdcaba7226c... there is:

+    Tuple!(int, int)[] arr;
+    arr ~= tuple(10, 20); // OK
+    arr ~= Tuple!(int, "x", int, "y")(10, 20); // NG -> OK

If I try to do the opposite, that is to append a tuple(10, 20) to 
an array of tuples with named fields, I get an error:

import std.typecons;
void main() {
     Tuple!(int, "x", int, "y")[] arr;
     arr ~= tuple(10, 20); // Error.
}


So here there is a true sub-typing. So sometimes tuples with 
named fields are sub-types and in other situations they act in a 
structural typing way. I think this mix of behaviours is a little 
confusing.

Bye,
bearophile
May 27 2013
next sibling parent "Kenji Hara" <k.hara.pg gmail.com> writes:
On Tuesday, 28 May 2013 at 00:29:04 UTC, bearophile wrote:

 std.typecons.Tuple supports "structural assignment" before the 
 change.
 The code also works with 2.062.


 I know it's not a regression. But you say:
 "Named-field tuple should be a subtype of unnamed-field tuple."

 You can have sub-typing, or you can have structural typing, but 
 mixing the two "silently" seems a mess.

 Also in your test cases of that commit fdcaba7226c... there is:

 +    Tuple!(int, int)[] arr;
 +    arr ~= tuple(10, 20); // OK
 +    arr ~= Tuple!(int, "x", int, "y")(10, 20); // NG -> OK

 If I try to do the opposite, that is to append a tuple(10, 20) 
 to an array of tuples with named fields, I get an error:

 import std.typecons;
 void main() {
     Tuple!(int, "x", int, "y")[] arr;
     arr ~= tuple(10, 20); // Error.
 }


 So here there is a true sub-typing. So sometimes tuples with 
 named fields are sub-types and in other situations they act in 
 a structural typing way. I think this mix of behaviours is a 
 little confusing.


Basically Tuple would follow structural typing. Even if it is 
impossible, it would follow true subtyping right now. That's the 
purpose of my change.

Kenji Hara
May 27 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 I will add it to Bugzilla then, if it's not already there.


http://d.puremagic.com/issues/show_bug.cgi?id=10192

Bye,
bearophile
May 28 2013