https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #1 from Manu <turkeyman@gmail.com> ---
Also this:

alias z = AliasSeq!(s.tupleof); // error, but it should be a no-op

--

https://issues.dlang.org/show_bug.cgi?id=24717

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org
            Summary|alias edge cases            |alias edge cases with
                   |                            |tupleof

--- Comment #2 from Nick Treleaven <nick@geany.org> ---
> alias y = s.tupleof[0]; // this is a compile error?!

Inside a function, `.tupleof` on a struct/static array instance should be implemented as a symbol sequence of implicit ref declarations:

struct S
{
    int i;
    char c;
}

void main()
{
    S s = {2, 'c'};
    ref __si = s.i;
    ref __sc = s.c;
    alias tupleof = AliasSeq!(__si, __sc); // should be the same as s.tupleof

    alias a = tupleof[0]; // works
    a++;
    assert(s.i == 3);

    alias z = AliasSeq!tupleof; // works
    assert(++z[0] == 4);
}

> alias z = AliasSeq!(s.tupleof); // error, but it should be a no-op

That line doesn't error, but using z does:

    z[0].writeln(); // Error: accessing non-static variable `x` requires an
instance of `S`

--

https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #3 from Nick Treleaven <nick@geany.org> ---
> should be implemented as a symbol sequence of implicit ref declarations

Actually `AliasSeq!(__si, __sc)` can't be the lowering because then
`__traits(identifier, s.tupleof[0])` would be `__si`, not `i`. But conceptually
it should be a superset of an lvalue sequence.

--

https://issues.dlang.org/show_bug.cgi?id=24717

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |enhancement

--- Comment #4 from Nick Treleaven <nick@geany.org> ---
> alias y = s.tupleof[0]; // this is a compile error?!

The error is:
Error: alias `y` cannot alias an expression `AliasSeq!(s.x)[0]`

That is because an alias declaration cannot target a value.

For:
struct S {
    int x;
    alias expand=Seq!x;
}

Turns out .tupleof is actually equivalent to the `expand` alias, see: https://forum.dlang.org/post/vaue5d$1quo$1@digitalmars.com

    alias z = AliasSeq!(s.tupleof);
    z[0].writeln(); // Error: accessing non-static variable `x` requires an
instance of `S`

So the above error is consistent with the design of symbol aliases. Changing this issue to an enhancement.

--

https://issues.dlang.org/show_bug.cgi?id=24717

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

--- Comment #5 from Nick Treleaven <nick@geany.org> ---
> That is because an alias declaration cannot target a value.

Sorry, s.x can be aliased as a symbol.

    alias y = s.tupleof[0]; // error
    alias x = s.x; // OK
    x.writeln; // error, no instance of S - correct by design

So there is a bug, the `y` alias should work like `x`.

--

https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #6 from Manu <turkeyman@gmail.com> ---
I just want to be clear again; it's definitely not "correct by design", it is absolutely, and proven time and time again over decades INCORRECT by design, and this just needs to be fixed.

The expression is expected to work by everyone who approaches it, and it should work.

--

https://issues.dlang.org/show_bug.cgi?id=24717

Max Samukha <maxsamukha@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxsamukha@gmail.com

--- Comment #7 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Manu from comment #6)
> decades INCORRECT by design

Not incorrect, but buggy and definitely not what most people expect.

--

https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #8 from Manu <turkeyman@gmail.com> ---
Nar, 'incorrect' is the only possible description, and I will die on this hill. "Most people" is an understatement ;)

'Explaining' things at the expense of reality is a physiological trap that our
kind fall into very easily.
This particular thing has gone on for way way too long, and it's time we put it
to bed.

--

https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #9 from Manu <turkeyman@gmail.com> ---
**psychological trap... bloody autocorrect!

--

https://issues.dlang.org/show_bug.cgi?id=24717

--- Comment #10 from Max Samukha <maxsamukha@gmail.com> ---
(In reply to Manu from comment #8)
> Nar, 'incorrect' is the only possible description, and I will die on this
> hill.
> "Most people" is an understatement ;)
> 
> 'Explaining' things at the expense of reality is a physiological trap that
> our kind fall into very easily.
> This particular thing has gone on for way way too long, and it's time we put
> it to bed.

Anyway, if you guys are going to "fix" that, please make sure that there is still a way to get a "contextless" reference to a member, that is, (an alternative of) this still works:

void apply(alias foo)(ref S s)
{
    assert (__traits(child, s, foo) == 1);

    int delegate() dg;
    dg.ptr = &s;
    dg.funcptr = &foo;
    assert(dg() == 1);
}

struct S
{
    int x;
    int foo() => x;
}

void main()
{
    S s = S(1);
    apply!(S.foo)(s);
}

--