Jump to page: 1 2
Thread overview
Trait or builtin that returns arguments passed to current function (if any)
Sep 09
bauss
Sep 09
Basile B.
Sep 09
Dennis
Sep 09
Basile B.
Sep 09
Basile B.
Sep 09
Tejas
Sep 09
Dukc
Sep 09
Dukc
Sep 09
bauss
Sep 09
bauss
Sep 13
bauss
September 08

Adam, and like others including me, are longing for a trait/builtin [1] that returns the parameters passed to the function of the current scope (if any). Has such a thing been proposed previously?

[1] http://dpldocs.info/this-week-in-d/Blog.Posted_2021_07_26.html#on-my-wish-list

September 09

On Wednesday, 8 September 2021 at 21:53:21 UTC, Per Nordlöw wrote:

>

Adam, and like others including me, are longing for a trait/builtin [1] that returns the parameters passed to the function of the current scope (if any). Has such a thing been proposed previously?

[1] http://dpldocs.info/this-week-in-d/Blog.Posted_2021_07_26.html#on-my-wish-list

While there isn't something directly that does it then it's fairly trivial to implement.

All you have to do to use it then is calling:

mixin(__ARGUMENTS__);

Here is the implementation:

string __ARGUMENTS__(string fn = __FUNCTION__)()
{
    import std.traits : ParameterIdentifierTuple;
    import std.array : join;

    mixin("enum parameterNames = [ParameterIdentifierTuple!(" ~ fn ~ ")];");

    return "auto __arguments = [" ~ parameterNames.join(",") ~ "];";
}

Here is a working example:

string __ARGUMENTS__(string fn = __FUNCTION__)()
{
    import std.traits : ParameterIdentifierTuple;
    import std.array : join;

    mixin("enum parameterNames = [ParameterIdentifierTuple!(" ~ fn ~ ")];");

    return "auto __arguments = [" ~ parameterNames.join(",") ~ "];";
}

void test(int x, int y)
{
    import std.stdio;

    mixin(__ARGUMENTS__);

    auto c = __arguments[0];
    auto d = __arguments[1];

    writefln("%d %d", c, d);
}

void main()
{
    test(1,2);
}

Output:
1 2

But yeah it would be nice if we could have it built-in, which I don't think has been done.

September 09

On Wednesday, 8 September 2021 at 21:53:21 UTC, Per Nordlöw wrote:

>

Adam, and like others including me, are longing for a trait/builtin [1] that returns the parameters passed to the function of the current scope (if any). Has such a thing been proposed previously?

[1] http://dpldocs.info/this-week-in-d/Blog.Posted_2021_07_26.html#on-my-wish-list

Why it should be a built-in? Apart from that requirement,
Parameters!(mixin(__FUNCTION__)) does the trick. A bit verbose but not much more so than the __traits(...) built-ins.

September 09

On Thursday, 9 September 2021 at 09:22:35 UTC, Dukc wrote:

>

Why it should be a built-in? Apart from that requirement,
Parameters!(mixin(__FUNCTION__)) does the trick. A bit verbose but not much more so than the __traits(...) built-ins.

Oh sorry, I see you meant an alias sequence to the parameters directly, not just their types. My bad.

September 09

On Thursday, 9 September 2021 at 09:22:35 UTC, Dukc wrote:

>

On Wednesday, 8 September 2021 at 21:53:21 UTC, Per Nordlöw wrote:

>

Adam, and like others including me, are longing for a trait/builtin [1] that returns the parameters passed to the function of the current scope (if any). Has such a thing been proposed previously?

[1] http://dpldocs.info/this-week-in-d/Blog.Posted_2021_07_26.html#on-my-wish-list

Why it should be a built-in? Apart from that requirement,
Parameters!(mixin(__FUNCTION__)) does the trick. A bit verbose but not much more so than the __traits(...) built-ins.

That doesn't do the same thing.

Parameters returns the type of each parameter.

__arguments in the case of OP holds the value of each parameter.

Parameters!(mixin(__FUNCTION__))

Ex. for a function like:

void a(int x, int y);

It'll actually give you:

(int, int)

When really OP wants:

[x, y]
September 09

On Thursday, 9 September 2021 at 09:28:17 UTC, bauss wrote:

>

On Thursday, 9 September 2021 at 09:22:35 UTC, Dukc wrote:

>

On Wednesday, 8 September 2021 at 21:53:21 UTC, Per Nordlöw wrote:

>

Adam, and like others including me, are longing for a trait/builtin [1] that returns the parameters passed to the function of the current scope (if any). Has such a thing been proposed previously?

[1] http://dpldocs.info/this-week-in-d/Blog.Posted_2021_07_26.html#on-my-wish-list

Why it should be a built-in? Apart from that requirement,
Parameters!(mixin(__FUNCTION__)) does the trick. A bit verbose but not much more so than the __traits(...) built-ins.

That doesn't do the same thing.

Parameters returns the type of each parameter.

__arguments in the case of OP holds the value of each parameter.

Parameters!(mixin(__FUNCTION__))

Ex. for a function like:

void a(int x, int y);

It'll actually give you:

(int, int)

When really OP wants:

[x, y]

The problem with ParameterIdentifierTuple which would give you the identifiers is that you get string representations of them, so you have to use them in a way like I did in my example above.

Because:

ParameterIdentifierTuple!(mixin(__FUNCTION__))

Gives you:

tuple("x", "y")
September 09

On Thursday, 9 September 2021 at 08:39:05 UTC, bauss wrote:

>

[...]
Here is a working example:

string __ARGUMENTS__(string fn = __FUNCTION__)()
{
    import std.traits : ParameterIdentifierTuple;
    import std.array : join;

    mixin("enum parameterNames = [ParameterIdentifierTuple!(" ~ fn ~ ")];");

    return "auto __arguments = [" ~ parameterNames.join(",") ~ "];";
}

void test(int x, int y)
{
    import std.stdio;

    mixin(__ARGUMENTS__);

    auto c = __arguments[0];
    auto d = __arguments[1];

    writefln("%d %d", c, d);
}

void main()
{
    test(1,2);
}

Output:
1 2

Nice.

>

But yeah it would be nice if we could have it built-in, which I don't think has been done.

That's a contemporary D question that often comes in conversations: should "feature x" be a builtin or should "feature x" be made using metaprog...

Is this used often ? is the metaprog version slow ?

September 09

On Thursday, 9 September 2021 at 10:14:03 UTC, Basile B. wrote:

>

That's a contemporary D question that often comes in conversations: should "feature x" be a builtin or should "feature x" be made using metaprog...

Is this used often ? is the metaprog version slow ?

Add "Is the metaprog version robust?". The given example doesn't work with test(T...)(T args), doesn't work with scope parameters, doesn't work with non-copyable ref parameters, etc. I know it's a proof of concept, but I'm not sure a seamless library solution is even possible with how many complexities there are with all kinds of variadic arguments and storage classes D has.

September 09

On Thursday, 9 September 2021 at 11:45:55 UTC, Dennis wrote:

>

On Thursday, 9 September 2021 at 10:14:03 UTC, Basile B. wrote:

>

That's a contemporary D question that often comes in conversations: should "feature x" be a builtin or should "feature x" be made using metaprog...

Is this used often ? is the metaprog version slow ?

Add "Is the metaprog version robust?". The given example doesn't work with test(T...)(T args), doesn't work with scope parameters, doesn't work with non-copyable ref parameters, etc. I know it's a proof of concept, but I'm not sure a seamless library solution is even possible with how many complexities there are with all kinds of variadic arguments and storage classes D has.

The answer is clear then ;)

Compilers traits dont require a DIP (IIRC) so just go on and be smart when answering the review comments.

September 09

On Thursday, 9 September 2021 at 12:48:03 UTC, Basile B. wrote:

>

On Thursday, 9 September 2021 at 11:45:55 UTC, Dennis wrote:

>

On Thursday, 9 September 2021 at 10:14:03 UTC, Basile B. wrote:

>

That's a contemporary D question that often comes in conversations: should "feature x" be a builtin or should "feature x" be made using metaprog...

Is this used often ? is the metaprog version slow ?

Add "Is the metaprog version robust?". The given example doesn't work with test(T...)(T args), doesn't work with scope parameters, doesn't work with non-copyable ref parameters, etc. I know it's a proof of concept, but I'm not sure a seamless library solution is even possible with how many complexities there are with all kinds of variadic arguments and storage classes D has.

The answer is clear then ;)

Compilers traits dont require a DIP (IIRC) so just go on and be smart when answering the review comments.

Compilers traits dont require a DIP (IIRC) so just go on with a PR and be
smart when answering the review comments.

« First   ‹ Prev
1 2