Jump to page: 1 2
Thread overview
[Issue 16343] Incorrectly requiring this pointer for a free function
Aug 01, 2016
Jonathan M Davis
Aug 01, 2016
Sobirari Muhomori
Aug 01, 2016
Jonathan M Davis
Aug 02, 2016
Sobirari Muhomori
Nov 19, 2017
Jonathan M Davis
Jun 20, 2019
Basile-z
Jun 20, 2019
Basile-z
Mar 21, 2020
Basile-z
Dec 17, 2022
Iain Buclaw
August 01, 2016
https://issues.dlang.org/show_bug.cgi?id=16343

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--
August 01, 2016
https://issues.dlang.org/show_bug.cgi?id=16343

Sobirari Muhomori <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec

--- Comment #1 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
Looks like tupleof returns a tuple of struct field aliases instead of a tuple of their types. And a template with an alias parameter requires a context through which it can access the aliased field. The question is what tupleof should return.

--
August 01, 2016
https://issues.dlang.org/show_bug.cgi?id=16343

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Yes, tupleof gives an AliasSeq of the fields in the struct - which is exactly what I want. It would be a major problem if it did something else. Also, there is no alias parameter here. It's a variadic template parameter, not an alias parameter. And note that this code compiles just fine:

void main()
{
    auto result = foo!(S.tupleof);
}

struct S
{
    int i;
}

template foo(fields...)
{
    enum foo = true;
}

It's just that when foo is a templated function instead of an eponymous template, you get the compilation error. So, something about foo being a function makes the compiler choke.

--
August 01, 2016
https://issues.dlang.org/show_bug.cgi?id=16343

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Accepting aliases that require 'this' shouldn't trigger an error either. It's when you try to use the alias that it should fail (if you fail to use the alias properly, that is).

--
August 02, 2016
https://issues.dlang.org/show_bug.cgi?id=16343

Sobirari Muhomori <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|spec                        |

--- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
Probably a duplicate of issue 13062. See also discussion in issue 11946 and its related issues. AFAIK there was a request to not require the context pointer for such templates, but can't find it now.

--
November 19, 2017
https://issues.dlang.org/show_bug.cgi?id=16343

--- Comment #5 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
I just hit this issue again - with an alias parameter this time. This code

============
struct S
{
    int i;
}

void main()
{
    foreach(memberName; __traits(allMembers, S))
    {
        func!(__traits(getMember, S, memberName))();
    }
}

void func(alias member)()
{
    auto protection = __traits(getProtection, member);
    alias Type = typeof(member);
    auto name = __traits(identifier, member);
}
============

gives this error

q.d(10): Error: need 'this' for 'func' of type 'pure nothrow @nogc @safe
void()'

whereas moving the contents of the free function into main works just fine. The lack of ability to pass the member to a template for introspection makes it a lot harder to avoid code duplication when writing code that does type introspection.

--
June 20, 2019
https://issues.dlang.org/show_bug.cgi?id=16343

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #6 from Basile-z <b2.temp@gmx.com> ---
In a way the message about "this" is not bogus. It has not been mentioned but if you set func "static" then the code works.

===
struct S
{
    int i;
}

void main()
{
    foreach(memberName; __traits(allMembers, S))
        func!(__traits(getMember, S, memberName));
}

static void func(alias member)()
{
    auto protection = __traits(getProtection, member);
    alias Type = typeof(member);
    auto name = __traits(identifier, member);
}
===

The real bug is that "func" seems to be injected in "S" (or considered as member of) for some reasons.

--
June 20, 2019
https://issues.dlang.org/show_bug.cgi?id=16343

--- Comment #7 from Basile-z <b2.temp@gmx.com> ---
A fix would be to infer "static"... but this is excessively hard since TemplateDeclaration and TemplateInstance are two different things and the real scope comes with the instance.

--
March 21, 2020
https://issues.dlang.org/show_bug.cgi?id=16343

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|b2.temp@gmx.com             |

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=16343

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--
« First   ‹ Prev
1 2