Re: Destructors can't be @nogc?
On Saturday, 24 July 2021 at 02:02:00 UTC, Mike Parker wrote: On Friday, 23 July 2021 at 20:24:02 UTC, Jim wrote: What is the problem here? Should I not call `destroy`? If so, what should I call instead? The problem is that you've marked main as `@nogc`, and `destroy` is not `@nogc`. Remove the annotation from main and it will compile. Which raises the question, *why* is `destroy` not `@nogc` when the destructor is `@nogc`? And it turns out the answer is that [it calls `rt_finalize`][1], which [takes its argument as a `void*`][2] and therefore has to assume that any destructor it calls *might* use the GC. [1]: https://github.com/dlang/druntime/blob/v2.097.1/src/object.d#L3970 [2]: https://github.com/dlang/druntime/blob/v2.097.1/src/rt/lifetime.d#L1438
Re: Destructors can't be @nogc?
On Friday, 23 July 2021 at 20:24:02 UTC, Jim wrote: What is the problem here? Should I not call `destroy`? If so, what should I call instead? The problem is that you've marked main as `@nogc`, and `destroy` is not `@nogc`. Remove the annotation from main and it will compile.
Re: how to test (at compilation-time) for existence of an already-declared object ?
On Saturday, 24 July 2021 at 01:44:11 UTC, Adam D Ruppe wrote:
On Saturday, 24 July 2021 at 01:29:26 UTC, someone wrote:
Suppose I have a module with the following:
static if(is(classTickerCustomNYSE))
// it was a valid type
else
// it was not a valid type
can use that to test. you can also mix in the name
static if(is(mixin("class name here"))) {}
There's similar tricks for testing for imports and such too but
i recommend here you import the module first then can test it.
is() ... faaan-tas-tic :)
I completely forgot about the is operator and went looking all
over the place for something like that.
Man ... leaving templates aside for a moment, conditional
compilation alongside mixin is pretty powerful in D ! I can't
believe how flexible code I am writing right now; and I am only a
beginner ...
Thanks for the tip Adam !
Re: how to test (at compilation-time) for existence of an already-declared object ?
On Saturday, 24 July 2021 at 01:29:26 UTC, someone wrote:
Suppose I have a module with the following:
static if(is(classTickerCustomNYSE))
// it was a valid type
else
// it was not a valid type
can use that to test. you can also mix in the name
static if(is(mixin("class name here"))) {}
There's similar tricks for testing for imports and such too but i
recommend here you import the module first then can test it.
how to test (at compilation-time) for existence of an already-declared object ?
Suppose I have a module with the following:
```d
public class classTickerCustomNYSE : classTickerCommon { ... }
public class classTickerCustomNASDAQ : classTickerCommon { ... }
```
... and given that I also have the following in the same module:
```d
public enum structureExchanges = [
r"NYSE"d : structureExchange(r"NYSE"d, r"New York Stock
Exchange"d, r"USD"d, r"usa"d, r"New York"d, r"EST"d),
r"NASDAQ"d : structureExchange(r"NASDAQ"d, r"National
Association of Securities Dealers Automated Quotations"d,
r"USD"d, r"usa"d, r"New York"d, r"EST"d),
r"LSE"d: structureExchange(r"LSE"d, r"London Stock
Exchange"d, r"GBP"d, r"gbr"d, r"London"d, r"UTC"d),
r"XETRA"d : structureExchange(r"XETRA"d, r"Deutsche Börse"d,
r"EUR"d, r"deu"d, r"Frankfurt am Main"d, r"CET"d),
r"B3"d : structureExchange(r"B3"d, r"B3 formerly Bolsa de
Valores de São Paulo (aka BOVESPA)"d, r"BRL"d, r"bra"d, r"São
Paulo"d, r"BRT"d),
r"BCBA"d : structureExchange(r"BCBA"d, r"Bolsa de Comercio
de Buenos Aires"d, r"ARS"d, r"arg"d, r"Buenos Aires"d, r"ART"d)
];
public struct structureExchange { /// solely‐intended to help
build code at compilation‐time; for client‐code classExchanges
should be used instead
public dstring ID;
public dstring name;
public dstring currencyID;
public typeLocation location;
@safe this(
const dstring lstrExchangeID,
const dstring lstrExchangeName,
const dstring lstrCurrencyID,
const dstring lstrCountryID,
const dstring lstrCity,
const dstring lstrTZ
) {
ID = lstrExchangeID;
name = lstrExchangeName;
currencyID = lstrCurrencyID;
location = typeLocation(
lstrCountryID,
lstrCity,
lstrTZ)
;
}
}
```
... at compilation-time I can do things like:
```d
static foreach (structureExchange sudtExchange;
structureExchanges) { /// assume the following code as a template
to build new classTickerCustom{ExchangeID} classes
mixin(format!
` /// code chunk
final public class classTickerCustom%1$s :
classTickerCommon {
...
}
`(sudtExchange.ID) /// code chunk
); /// mixin ending
}
```
... now, question is: how can I check, within the static foreach
code, whether a class is already-implemented or not; eg:
```d
static foreach (structureExchange sudtExchange;
structureExchanges) {
if (! ? == r"classTickerCustom"d ~ sudtExchange.ID) {
/// class is not implemented yet: do whatever here ...
}
}
```
... my first thought was traits
(https://dlang.org/spec/traits.html) but I don't see anything
useful there; there is getMember() but the example is for
already-declared objects within the module, and not the module
itself.
Re: Build time
On Friday, 23 July 2021 at 19:09:02 UTC, JG wrote: I am not sure how relevant it is but it is a compiler that I have been writing, not something serious (yet - if ever). Compile time optimizations are a bit weird compared to runtime ones - things that would fast at run time may actually be very slow at compile time, so eyeballing the code might help me point out something to consider.
Re: POST request with std.net.curl
On Friday, 23 July 2021 at 19:59:33 UTC, Ali Çehreli wrote:
On 7/23/21 11:11 AM, bachmeier wrote:
I'm writing a D program that interacts with the Todoist API
using std.net.curl. It's not a problem to do get requests to
query tasks, but I cannot find a way to get post to work to
create a new task.
This is a working bash script, where APIKEY is defined
elsewhere and $1 and $2 are user input when running the script:
```
curl "https://api.todoist.com/rest/v1/tasks; -X POST --data
"{"'"'"content"'"'": "'"'"$1"'"'", "'"'"project_id"'"'": $2}"
-H "Content-Type: application/json" -H "Authorization: Bearer
$APIKEY"
```
(For obvious reasons I'm not going to provide a working
example.) How can I translate this into a post function call
within D?
[Todoist API
Reference](https://developer.todoist.com/rest/v1/?shell#create-a-new-task)
I haven't used it but isn't it the version of post that takes a
dictionary here?
https://dlang.org/phobos/std_net_curl.html#.post
If the Authorization is the problem, I wonder whether
addRequestHeader is the solution:
https://dlang.org/phobos/std_net_curl.html#.HTTP.addRequestHeader
Ali
Authorization is working - it's the same whether I'm doing a GET
or POST request. The problem is passing the data. The main
problem is that the documentation doesn't explain how to
translate a `--data` option into a `post` call. I've tried
everything I can think of, including what's shown in the
documentation, but haven't found anything that works.
testFilename in std.stdio
Hi everyone.
I have a file main.d
```
import std.stdio: writeln;
int main (string []) { return 0; }
```
When I try to get depend files with command `ldc2 main.d
--unittest --deps=main.deps --o-` such errors are received:
```
/home/mak/progs/ldc2-1.26.0-linux-x86_64/bin/../import/std/stdio.d(563): Error:
undefined identifier `testFilename`
/home/mak/progs/ldc2-1.26.0-linux-x86_64/bin/../import/std/stdio.d(759): Error:
undefined identifier `testFilename`
/home/mak/progs/ldc2-1.26.0-linux-x86_64/bin/../import/std/stdio.d(765): Error:
undefined identifier `testFilename`
/home/mak/progs/ldc2-1.26.0-linux-x86_64/bin/../import/std/stdio.d(781): Error:
undefined identifier `testFilename`
...
```
Is it possible that the std/stdio.d function
[`testFilename`](https://github.com/dlang/phobos/blob/adff6577b9fd5f512ec348494e8037a0bb71b89f/std/stdio.d#L5908) wrapped in `version (StdUnittest)` is in version (unittest) ?
version of ldc - 1.26.0
Destructors can't be @nogc?
Hello,
I've been playing with D and trying to understand how to work
with @nogc. I must be doing something wrong, because even though
I tagged the destructor for my class `@nogc`, I'm getting the
following error: `.\min.d(27): Error: "@nogc" function "D main"
cannot call non-@nogc function "object.destroy!(true,
TestClass).destroy`
```D
import std.stdio : printf;
import core.lifetime : emplace;
import core.stdc.stdlib : malloc, free;
class TestClass {
int x;
this(int x) @nogc {
printf("TestClass's constructor called\n");
this.x = x;
}
~this() @nogc {
printf("TestClass's destructor called\n");
}
}
@nogc void
main() {
auto size = __traits(classInstanceSize, TestClass);
auto memory = malloc(size)[0..size];
TestClass x = emplace!(TestClass)(memory, 1);
printf("TestClass.x = %d\n", x.x);
destroy(x);
free(cast(void*)x);
}
```
What is the problem here? Should I not call `destroy`? If so,
what should I call instead?
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/23/21 3:30 PM, apz28 wrote: On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote: On 7/22/21 7:43 PM, apz28 wrote: In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. The -debug build with passing unit-tests so no problem there. The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD That is a separate problem. That build is hung, and you likely have found a bug in the compiler. I have never seen a build last more than a few minutes at the most. If the code you posted is not crashing with a segfault, then it's possible there is a code generation issue. I still believe you have your check backwards. -Steve
Re: Build time
On Friday, 23 July 2021 at 19:32:08 UTC, H. S. Teoh wrote: And avoid doing too much work in CTFE, which is known to be slow. Well it very much depends HOW you do it. Like the ~= operation in ctfe is awfully slow and wastes a lot of memory depending on the size of the string, but if you preallocate and copy memory in chunks it isn't too bad at all. And if you use format!"str"() in ctfe that alone can be a real speed killer. That's why I wanna see the code, it is possible there's a fairly simple bottleneck to look at.
Re: Build time
On Friday, 23 July 2021 at 18:53:06 UTC, JG wrote: Any suggestion on how to try and improve the build time. I am currently using dub. You can try profiling it with LDC 1.25 or later. Add this to dub.sdl: ``` dflags "--ftime-trace" platform="ldc" dflags "--ftime-trace-file=./my-trace.json" platform="ldc" postBuildCommands "import-chrome ./my-trace.json ./my-trace.tracy" platform="ldc" ``` You can [get import-chrome and tracy here](https://github.com/wolfpld/tracy). There's binaries for Windows, and on Ubuntu/Debian Linux you can install as follows: ``` # Install required packages (there may be more, but this was the only one I didn't have installed yet) sudo apt install libcapstone-dev # Go to your code folder and clone tracy: git clone https://github.com/wolfpld/tracy # Build the import-chrome tool cd tracy/import-chrome/build/unix/ make # Copy it to the /usr/local/bin folder so it can be invoked from anywhere sudo cp import-chrome-release /usr/local/bin/import-chrome # Back to the root of the repo, now build the profiler cd ../../../ cd profiler/build/unix/ make sudo cp Tracy-release /usr/local/bin/tracy ``` Then do: ``` dub build --compiler=ldc2 tracy my-trace.tracy ``` And you can inspect what functions the compiler spends the most time on compiling. Sometimes there's one dumb thing taking a lot of time, so you can improve build times by working around that. E.g. I once replaced `std.conv: text` with `snprintf` to reduce my build time from 2.1 to 1.6 seconds.
Re: POST request with std.net.curl
On 7/23/21 11:11 AM, bachmeier wrote:
I'm writing a D program that interacts with the Todoist API using
std.net.curl. It's not a problem to do get requests to query tasks, but
I cannot find a way to get post to work to create a new task.
This is a working bash script, where APIKEY is defined elsewhere and $1
and $2 are user input when running the script:
```
curl "https://api.todoist.com/rest/v1/tasks; -X POST --data
"{"'"'"content"'"'": "'"'"$1"'"'", "'"'"project_id"'"'": $2}" -H
"Content-Type: application/json" -H "Authorization: Bearer $APIKEY"
```
(For obvious reasons I'm not going to provide a working example.) How
can I translate this into a post function call within D?
[Todoist API
Reference](https://developer.todoist.com/rest/v1/?shell#create-a-new-task)
I haven't used it but isn't it the version of post that takes a
dictionary here?
https://dlang.org/phobos/std_net_curl.html#.post
If the Authorization is the problem, I wonder whether addRequestHeader
is the solution:
https://dlang.org/phobos/std_net_curl.html#.HTTP.addRequestHeader
Ali
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/23/21 12:30 PM, apz28 wrote: > The -debug build with passing unit-tests so no problem there. > The -release build is having problem. After make change to accommodate > it, it takes forever to build. I started it yesterday 11AM and it is > still compiling now (more than a day already.) It takes a full 100% core > and peek memory usage is 2.2GB. The hard-drive is SSD There is definitely something wrong with the compiler. That build time is ridiculously high. Ali
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On Friday, 23 July 2021 at 18:44:47 UTC, Steven Schveighoffer wrote: On 7/22/21 7:43 PM, apz28 wrote: In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. -Steve The -debug build with passing unit-tests so no problem there. The -release build is having problem. After make change to accommodate it, it takes forever to build. I started it yesterday 11AM and it is still compiling now (more than a day already.) It takes a full 100% core and peek memory usage is 2.2GB. The hard-drive is SSD
Re: Build time
On Fri, Jul 23, 2021 at 06:53:06PM +, JG via Digitalmars-d-learn wrote: [...] > The program I writing is around 3000 loc and recently I noticed a > large slow down in compile time which after investigation seemed to be > caused by my computer running out of memory. The compile was using > more than 15GB memory. I tried using lowmem and that did solve the > memory problem but the compile still takes around 1 minute. Any > suggestion on how to try and improve the build time. I am currently > using dub. 3000 loc and 1 minute build time? Sounds like you're using too many nested templates / CTFE. > Of course one could try to use fewer templates and less meta > programming but that seems to defeat the purpose of using d. I wouldn't say use fewer templates / less meta-programming. But I'd say look into how deeply nested templates are, and whether some templates parameters may be unnecessary. If you have recursive templates, consider refactoring it so that it uses linear expansion instead. Shallowly-nested templates generally don't run into performance problems. (Confession: I wrote the variadic version of cartesianProduct in std.algorithm with recursive templates. It uses an exponential number of template expansions, and so quickly brings the compiler to its knees when you try to take 4 or more cartesian products in a row. Eventually, I refactored the most common case (no infinite ranges among its arguments) to use a linear expansion with a nested loop instead. Compile times improved by a HUGE margin.) And avoid doing too much work in CTFE, which is known to be slow. But not as slow as overly-deeply nested templates. Another way is to have a separate build step for expanding the most heavy templates, so that you only incur that heavy expansion once in a while when you change the relevant code. I had a Vibe.d project where Diet templates slowed me down too much (they are super template-heavy), so I split it into several different build targets with a separate link step, so that when I'm not changing the Diet templates it doesn't slow me down so much. Dub unfortunately won't help you here (unless you use subpackages -- but I doubt it will win much) -- I recommend using a better build system like CMake or SCons. Dub's architecture simply does not play well with staged compilation. Alternatively, use a separate pre-compilation stage for generating code (e.g., write a utility that emits D code that then gets compiled in a subsequent step). As much as I love D's compile-time capabilities, there comes a time when it's simply more practical to just `writefln` some D code snippets into a file and compile that into the main program, instead of trying to tame the memory-guzzling beast that is the D compiler. T -- I am Ohm of Borg. Resistance is voltage over current.
Re: Build time
On Friday, 23 July 2021 at 18:57:46 UTC, Adam D Ruppe wrote: On Friday, 23 July 2021 at 18:53:06 UTC, JG wrote: The program I writing is around 3000 loc what's the code? I am not sure how relevant it is but it is a compiler that I have been writing, not something serious (yet - if ever).
Re: Build time
On Friday, 23 July 2021 at 18:53:06 UTC, JG wrote: The program I writing is around 3000 loc what's the code?
Build time
Hi, The program I writing is around 3000 loc and recently I noticed a large slow down in compile time which after investigation seemed to be caused by my computer running out of memory. The compile was using more than 15GB memory. I tried using lowmem and that did solve the memory problem but the compile still takes around 1 minute. Any suggestion on how to try and improve the build time. I am currently using dub. Of course one could try to use fewer templates and less meta programming but that seems to defeat the purpose of using d.
Re: enum true, or 1
On 7/22/21 1:44 PM, Brian Tiffin wrote: > So would there be any cringes Not from me. :) > seeing a skeleton D source file that > always ended with > > ~~~d > /++ > Disclaimer > > This software is distributed in the hope that it will be useful, but > WITHOUT ANY WARRANTY; direct or indirect, without even the implied > warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > +/ > enum INDEMNITY = true; > ~~~ ?? > > The goal is attaching backmatter doc comments to a declaration that > follows without being too intrusive. I don't feel qualified to comment on such a topic but it looks fine. Perhaps INDEMNIFIED is more grammatically correct but weirder too. :) Ali
Re: How to Fix Weird Build Failure with "-release" but OK with "-debug"?
On 7/22/21 7:43 PM, apz28 wrote: FbConnection is a class, FbXdrReader is a struct and for this call, response.data is not null & its' length will be greater than zero and FbConnection is not being used. So why DMD try to evaluate at compiled time hence error 1. Should not evaluate at compile time for this function call/construct 2. The error message is missing proper line # or nothing related to the module displayed in error message https://github.com/apz28/dlang/blob/main/source/pham/db/db_fbbuffer.d#L527 I have a feeling that line is backwards. It says: if the buffer has length, ignore it and use the connection, otherwise use the (empty) buffer data. So perhaps this is actually a real error that is being flagged (because it's inlined)? In any case, it's possible that fbConnection being null does not mean a null dereference, but I'd have to see the class itself. I'm surprised if you don't get a null dereference in non-release mode, unless this code is never actually called. -Steve
POST request with std.net.curl
I'm writing a D program that interacts with the Todoist API using
std.net.curl. It's not a problem to do get requests to query
tasks, but I cannot find a way to get post to work to create a
new task.
This is a working bash script, where APIKEY is defined elsewhere
and $1 and $2 are user input when running the script:
```
curl "https://api.todoist.com/rest/v1/tasks; -X POST --data
"{"'"'"content"'"'": "'"'"$1"'"'", "'"'"project_id"'"'": $2}" -H
"Content-Type: application/json" -H "Authorization: Bearer
$APIKEY"
```
(For obvious reasons I'm not going to provide a working example.)
How can I translate this into a post function call within D?
[Todoist API
Reference](https://developer.todoist.com/rest/v1/?shell#create-a-new-task)
Re: Cannot always deduce template arguments when using implicitly cast array literals
On Friday, 23 July 2021 at 14:41:41 UTC, Paul Backus wrote: The first is to change the type of right from const R to const T[L1], which removes the type specialization: Thanks for suggesting that fix, removing R altogether is a very simple solution I hadn't considered. :) Unfortunately, the algorithm it uses for this is not very sophisticated, and does not take type specializations (like `R : T[L1]`) into account. This seems like a slight oversight to me, do you know if there would be any chance of this changing in the future?
Re: Cannot always deduce template arguments when using implicitly cast array literals
On Friday, 23 July 2021 at 13:53:27 UTC, Rekel wrote:
After simplifying a part of my code I found the following code
cannot deduce the template arguments, but I have no clue why.
```d
void foo(L : T[L1][L2], uint L1, uint L2, T, R:
T[L1])(const L left, const R right) {
// Function
}
void bar(uint L)(float[L] l) {
// Function
}
void main(string[] args) {
bar([1.0f, 2, 3, 4, 5, 6, 7, 8]); // implicitly cast to
float[8], works
float[4][1] l = [[1, 2, 3, 4]];
foo!(typeof(l), 4, 1, float, float[4])(l, [1.0f, 2, 3, 4]); //
also works
foo(l, [1.0f, 2, 3, 4]); // cannot deduce function from
argument types (?)
}
```
As one can see, implicitly casting array literals in templates
works fine in the case of bar, as does explicit use of
templates in the case of foo, but for some reason foo does not
manage to deduce its arguments like bar does.
Looks like the problem is that the compiler is interpreting
`[1.0f, 2, 3, 4]` as a dynamic array (`float[]`) instead of a
static array (`float[4]`).
Array literals are treated as dynamic arrays by default, and as
static arrays only in specific contexts where the compiler is
able to determine that a static array is required. Unfortunately,
the algorithm it uses for this is not very sophisticated, and
does not take type specializations (like `R : T[L1]`) into
account.
There are two ways you can solve this. The first is to change the
type of `right` from `const R` to `const T[L1]`, which removes
the type specialization:
```d
void foo(L : T[L1][L2], uint L1, uint L2, T)
(const L left, const T[L1] right)
{
// Function
}
```
The second is to use `std.array.staticArray` to manually cast the
array literal to a static array:
```d
import std.array: staticArray;
foo(l, staticArray!([1.0f, 2, 3, 4]));
```
Cannot always deduce template arguments when using implicitly cast array literals
After simplifying a part of my code I found the following code
cannot deduce the template arguments, but I have no clue why.
```d
void foo(L : T[L1][L2], uint L1, uint L2, T, R:
T[L1])(const L left, const R right) {
// Function
}
void bar(uint L)(float[L] l) {
// Function
}
void main(string[] args) {
foo2([1.0f, 2, 3, 4, 5, 6, 7, 8]); // implicitly cast to
float[8], works
float[4][1] l = [[1, 2, 3, 4]];
foo!(typeof(l), 4, 1, float, float[4])(l, [1.0f, 2, 3, 4]); //
also works
foo(l, [1.0f, 2, 3, 4]); // cannot deduce function from argument
types (?)
}
```
As one can see, implicitly casting array literals in templates
works fine in the case of bar, as does explicit use of templates
in the case of foo, but for some reason foo does not manage to
deduce its arguments like bar does.
The type of l is well known, and given the template, the type of
R should thus be known as well. T[L1] should be deduced to
float[4].
Did I make a mistake in the argument list? I know things like the
order are sometimes issues, but that seems fine to me here.
Seeing as bar functions fine (as does foo when R and right are
removed) I'm at a loss.
Thanks you in advance!
Re: associative array with Parallel
On Thursday, 22 July 2021 at 16:39:45 UTC, Steven Schveighoffer wrote: On 7/22/21 1:46 AM, seany wrote: [...] Correct. You must synchronize on ii. [...] This isn't valid code, because you can't append to an integer. Though I think I know what you meant. Is it thread-safe (assuming the array elements are appendable)? I think so, but I'd have to see a working example. [...] you are right. in the pseudocode, i wanted to say: `ii[i] = somefunc(dummy);`
Re: Generate docs for generated code?
On Friday, 23 July 2021 at 10:54:33 UTC, Adam D Ruppe wrote:
On Friday, 23 July 2021 at 10:04:55 UTC, wjoe wrote:
Is there a way for the compiler to consider doc comments in
auto generated, mixed in code?
If you use my adrdox generator (which runs on the dpldocs.info
website), it handles mixin templates. See
http://dpldocs.info/experimental-docs/std.net.curl.HTTP.html#mixed-in-members
for example.
Mine also actually handles
mixin(q{
/// code
void foo() {}
});
as if it was direct.
But my generator only handles mixin templates and mixin string
literals, not actually generated code returned from a function.
Cool! I take it.
Thanks for making adrdox :)
Re: Generate docs for generated code?
On Friday, 23 July 2021 at 10:42:22 UTC, user1234 wrote:
On Friday, 23 July 2021 at 10:04:55 UTC, wjoe wrote:
Is there a way for the compiler to consider doc comments in
auto generated, mixed in code?
E.g.
```D
string fooImpl = q{
/// Bar does fancy things.
const void bar() { /*do something fancy*/ }
};
/// This is Foo
struct Foo(A, B, C) {
mixin(fooImpl);
}
```
So that the documentation for ```struct Foo``` has that of the
member ```bar()``` ?
unfortunately no and this is considered as a
[bug](https://issues.dlang.org/show_bug.cgi?id=2420)
bummer but thanks for the link.
Re: Generate docs for generated code?
On Friday, 23 July 2021 at 10:04:55 UTC, wjoe wrote:
Is there a way for the compiler to consider doc comments in
auto generated, mixed in code?
If you use my adrdox generator (which runs on the dpldocs.info
website), it handles mixin templates. See
http://dpldocs.info/experimental-docs/std.net.curl.HTTP.html#mixed-in-members
for example.
Mine also actually handles
mixin(q{
/// code
void foo() {}
});
as if it was direct.
But my generator only handles mixin templates and mixin string
literals, not actually generated code returned from a function.
Re: Generate docs for generated code?
On Friday, 23 July 2021 at 10:04:55 UTC, wjoe wrote:
Is there a way for the compiler to consider doc comments in
auto generated, mixed in code?
E.g.
```D
string fooImpl = q{
/// Bar does fancy things.
const void bar() { /*do something fancy*/ }
};
/// This is Foo
struct Foo(A, B, C) {
mixin(fooImpl);
}
```
So that the documentation for ```struct Foo``` has that of the
member ```bar()``` ?
unfortunately no and this is considered as a
[bug](https://issues.dlang.org/show_bug.cgi?id=2420)
Generate docs for generated code?
Is there a way for the compiler to consider doc comments in auto
generated, mixed in code?
E.g.
```D
string fooImpl = q{
/// Bar does fancy things.
const void bar() { /*do something fancy*/ }
};
/// This is Foo
struct Foo(A, B, C) {
mixin(fooImpl);
}
```
So that the documentation for ```struct Foo``` has that of the
member ```bar()``` ?
