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

Reply via email to