Re: std.traits.ParameterIdentifierTuple problem
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.
Re: std.traits.ParameterIdentifierTuple problem
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.
Re: std.traits.ParameterIdentifierTuple problem
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!
Re: std.traits.ParameterIdentifierTuple problem
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.
Re: std.traits.ParameterIdentifierTuple problem
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`.
Re: std.traits.ParameterIdentifierTuple problem
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?
Re: std.traits.ParameterIdentifierTuple problem
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.
std.traits.ParameterIdentifierTuple problem
Using the [ParameterIdentifierTuple](https://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple) 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?
LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr nonnull
%rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr nonnull
%284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
Re: Best way to use large C library in D as of 2024
On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote: @D Language Foundation - This is a HUGE selling point. I had to use cups the other day and I just copied some code from a d file and linked the library. It was so easy I was suspicious but it worked. Using C from D is pretty much as easy as using C from C and I think you should advertise that better! Though I appreciate the sentiment, it's much more effective and efficient for people actually using the feature, and who appreciate it, to write up a blog post about it somewhere and share that on Twitter/Reddit/HN, etc. Just a handful of people doing that would potentially reach a wider audience, they'd be able to show the feature in use in actual code, and their words will probably carry more weight as a language user than someone from the DLF. There's a world of difference between showing it in use in a real-world project vs. showing examples of how it can be used, which is all that I'd be able to do if I were to write about it. And that goes for anything that makes you think "the DLF should advertise this". I mean, when I had time to prioritize the blog, I was regularly writing articles about cool D features, and sometimes getting others to write guest posts about their projects or whatever. But that's pretty much like one person standing on a hilltop with a megaphone, periodically handing it off to someone else. How many other people from the D community were adding their voices? Now and then, someone would write something up somewhere, but it wasn't happening regularly or often. Anyone happy using D, who wants to see it continue to grow and improve, can help toward that end by telling the world about it. That said, if there's anyone out there who would like to take on management of the blog and make it more active, I'd love to hear from you.
Re: How to make fields inaccessible (unreadable and unachangeable) outside of the structure?
On Saturday, 30 March 2024 at 03:25:02 UTC, matheus wrote: Interesting! Matheus. Yes, it's just a small modification.
