www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.traits.ParameterIdentifierTuple problem

reply Carl Sturtivant <sturtivant gmail.com> writes:
Using the 
[ParameterIdentifierTuple](https://dlang.org/phobos/std_traits.html#Param
terIdentifierTuple) example just there, with one more step stops working.
Details:
```D
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?
Mar 30
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 30 March 2024 at 19:23:07 UTC, Carl Sturtivant wrote:

 $ 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?


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.
Mar 30
next sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Saturday, 30 March 2024 at 21:07:35 UTC, Nick Treleaven wrote:

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

 $ 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?


 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.


OK, so how can I get them? Am I forced to take that string and 
parse it with CTFE?
Mar 30
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 30 March 2024 at 21:25:45 UTC, Carl Sturtivant wrote:

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


Lookup the source of ParameterIdentifierTuple and change 
`FunctionTypeOf!func` to just `func` inside the first `static if`.
Mar 30
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 30 March 2024 at 21:45:34 UTC, Nick Treleaven wrote:

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

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


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


Sorry, that actually doesn't work.
Mar 30
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Saturday, 30 March 2024 at 21:51:34 UTC, Nick Treleaven wrote:

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

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

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


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


 Sorry, that actually doesn't work.


I appreciate you actually having a shot at this! No apology 
necessary!
Mar 30
prev sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Saturday, 30 March 2024 at 21:07:35 UTC, Nick Treleaven wrote:

 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.


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
```D
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.
Mar 30
next sibling parent Carl Sturtivant <sturtivant gmail.com> writes:
On Saturday, 30 March 2024 at 22:37:53 UTC, Carl Sturtivant wrote:

 Incidentally, I tried
 ```D
 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.


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
```D
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.
Mar 30
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 30 March 2024 at 22:37:53 UTC, Carl Sturtivant 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.


Maybe, but one of its unittests specifically tests that a 
function pointer has no parameter identifiers:
```d
     // 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`?


 Incidentally, I tried
 ```D
 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,


Nice try!


 but the compiler said `bug1.d(5): Error: variable ``bug1.func`` 
 cannot be declared to be a function`. Seems unreasonable given 
 the implied semantics.


Yes, it's not possible to instantiate a function type.
Mar 31
parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Sunday, 31 March 2024 at 11:35:39 UTC, Nick Treleaven wrote:

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


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


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


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?
Mar 31
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 31 March 2024 at 23:05:44 UTC, Carl Sturtivant wrote:

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


 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?


Yes there is no instantiation for extern. But what would be the 
use of allowing an extern function type instance, when there's no 
way to instantiate it?
Apr 01
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Monday, 1 April 2024 at 18:28:16 UTC, Nick Treleaven wrote:

 On Sunday, 31 March 2024 at 23:05:44 UTC, Carl Sturtivant wrote:

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


 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?


 Yes there is no instantiation for extern. But what would be the 
 use of allowing an extern function type instance, when there's 
 no way to instantiate it?


1. For compile time work that uses the name but not the function 
it nominally refers to. That's what I wanted it for: 
`ParameterIdentifierTuple` might actually work on that.

2. In fact the definition might refer to a function defined in 
another module, for example brought in by ImportC. It's an 
alternative way of writing the signature of an external function. 
Why rule it out when it is reasonable?

The first could also work with an explicitly uninstantiated 
function, as in `enum FUNCTYPE f = void;` hence my second attempt 
above.

As long as there are compile-time actions that work on functions 
but not their types, this would be a way to work around that.
Apr 02