Using the ParameterIdentifierTuple example just there, with one more step stops working. Details:

import std.traits;
int foo(int num, string name, int);
static assert([ParameterIdentifierTuple!foo] == ["num", "name", ""]);

alias signature = typeof(foo);
pragma(msg, signature.stringof);
enum names = [ParameterIdentifierTuple!signature];
pragma(msg, names.stringof);
static assert(names==["num","name",""], "wrong!");

Output on compilation:

$ dmd --version
DMD64 D Compiler v2.107.0
Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved written by Walter Bright

$ dmd -c bug1.d
int(int num, string name, int)
["", "", ""]
bug1.d(9): Error: static assert:  "wrong!"

Please explain. How do I get the names of the identifiers out of a parameter list at compile time reliably?

On Saturday, 30 March 2024 at 19:23:07 UTC, Carl Sturtivant wrote:

Please explain. How do I get the names of the identifiers out of a parameter list at compile time reliably?

Although .stringof on a function type does include the parameter names, the names are not really part of the type - see:
https://github.com/dlang/phobos/pull/3620#issuecomment-288469685

Perhaps ParameterIdentifierTuple should give a compile error when given a function type.

On Saturday, 30 March 2024 at 21:07:35 UTC, Nick Treleaven wrote:

Please explain. How do I get the names of the identifiers out of a parameter list at compile time reliably?

OK, so how can I get them? Am I forced to take that string and parse it with CTFE?

On Saturday, 30 March 2024 at 21:25:45 UTC, Carl Sturtivant wrote:

Lookup the source of ParameterIdentifierTuple and change FunctionTypeOf!func to just func inside the first static if.

On Saturday, 30 March 2024 at 21:45:34 UTC, Nick Treleaven wrote:

Sorry, that actually doesn't work.

On Saturday, 30 March 2024 at 21:51:34 UTC, Nick Treleaven wrote:

I appreciate you actually having a shot at this! No apology necessary!

On Saturday, 30 March 2024 at 21:07:35 UTC, Nick Treleaven wrote:

I'm inclined to a view that keeps more "it just works" options open. Regard the parameter names as a part of the type (which I am very grateful for them being currently) and just regard part of the definition of "type equality" as being to ignore parameter names when comparing types.

With this viewpoint, ParameterIdentifierTuple should be repaired to work with function types just as it works with functions, and the current behavior is a bug.

Incidentally, I tried

extern typeof(foo) func;

to say that func was an actual function (extern so defined elsewhere) whose type was the type of the function int foo(int num, string name, int); so I can then use ParameterIdentifierTuple on a function, not a type, but the compiler said bug1.d(5): Error: variable ``bug1.func`` cannot be declared to be a function. Seems unreasonable given the implied semantics.

On Saturday, 30 March 2024 at 22:37:53 UTC, Carl Sturtivant wrote:

extern typeof(foo) func;

The word variable in that error message caught my eye and it struck me that in some sense a function is a constant, not a variable, we have function pointers for the last. So I tried

enum typeof(foo) func = void;

to see if I could escape this difficulty. Sadly got exactly the same error message, even though no variable was involved.

On Saturday, 30 March 2024 at 22:37:53 UTC, Carl Sturtivant wrote:

Maybe, but one of its unittests specifically tests that a function pointer has no parameter identifiers:

    // might be changed in the future?
    void function(int num, string name) fp;
    static assert([ParameterIdentifierTuple!fp] == ["", ""]);

And changing in the future got quite a bit of push back in that PR link.

This is because fp is declared using a function pointer type, and the author of the test did not think function pointer types should include identifiers. So it seems logical that ParameterIdentifierTuple should not give identifiers for a function type either.

If a function type does include identifiers, then would two function types with the same argument types but different identifiers compare equal using is?

extern typeof(foo) func;

Nice try!

Yes, it's not possible to instantiate a function type.

On Sunday, 31 March 2024 at 11:35:39 UTC, Nick Treleaven wrote:

Yes. That is the idea. Define is to work this way.

But with extern it seems the semantics is fine as a function is not being instantiated. It is merely associating a name with a type: in what sense is this instantiation in any reasonable way?