Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
May 27, 2013 Two questions about assignments | ||||
---|---|---|---|---|
| ||||
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 Re: Two questions about assignments | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 28, 2013 Re: Two questions about assignments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | 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 28, 2013 Re: Two questions about assignments | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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 28, 2013 Re: Two questions about assignments | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > 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 |
Copyright © 1999-2021 by the D Language Foundation