Refer to https://github.com/dlang/phobos/commit/8becc70da790826bccec734d40021dd7ff22f485.
Currently we implement the correct subtyping by means of a cast, which does not work during compilation.
A better implementation would be to have the Tuple with named fields use the Tuple with no named fields as its only member variable; then, "alias this" needs to simply return a reference to that member.
Comment #1 by greensunny12 — 2018-02-12T19:38:04Z
A minimal testcase
---
alias point = Tuple!(int, "x", int, "y");
static assert(point(2, 2)[0] == 0);
---
Comment #2 by greensunny12 — 2018-02-12T20:51:44Z
And a stripped down version of std.typecons.Tuple:
https://gist.github.com/wilzbach/0a55a571f1c46e9d59420cf158354b85
> A better implementation would be to have the Tuple with named fields use the Tuple with no named fields as its only member variable; then, "alias this" needs to simply return a reference to that member.
This is already done:
struct Tuple
{
Types expand; // e.g. AliasSeq!(int, int)
}
However, if `alias expand this` is used, this stops to work:
---
auto t1 = Tuple!(int, "x", string, "y")(1, "a");
void foo(Tuple!(int, string) t2) {}
foo(t1);
---
foo.d(149): Error: function foo.__unittest_L143_C7.foo(Tuple!(int, string) t2) is not callable using argument types (Tuple!(int, "x", string, "y"))
foo.d(149): cannot pass argument t1 of type Tuple!(int, "x", string, "y") to parameter Tuple!(int, string) t2
Comment #3 by andrei — 2018-02-12T22:04:49Z
(In reply to Seb from comment #2)
> And a stripped down version of std.typecons.Tuple:
>
> https://gist.github.com/wilzbach/0a55a571f1c46e9d59420cf158354b85
>
> > A better implementation would be to have the Tuple with named fields use the Tuple with no named fields as its only member variable; then, "alias this" needs to simply return a reference to that member.
>
> This is already done:
Nonono, we need to do this:
Tuple!(int, "x", int, "y") should have as its only state Tuple!(int, int). In the form of a data member that is. Call that field impl. Then:
alias impl this;
Comment #4 by robert.schadek — 2024-12-01T16:32:39Z