Re: Why does this mixin fail to compile?
On Monday, 1 July 2024 at 13:00:55 UTC, ryuukk_ wrote:
please stick to what i wrote, i don't want string
concatenation, i provide a reduced example from my project,
everything should be a single template block, no extra
functions other than the append() one
Mixin templates are a declaration scope, not a function scope, so
they aren't necessarily analyzed top to bottom. This is why
allowing partial string mixins would be complicated, consider
this example:
```D
mixin template implement()
{
mixin("struct " ~ str);
mixin("{");
immutable string str = "T";
mixin("}");
}
```
It's not obvious how this should be compiled, and this is before
throwing `static if` and `static foreach` in the mix! If you want
to procedurally build a type in sequential steps, you'll have to
do that in a function scope.
If your concern is that such a function would add needless code
generation, you can use an immediately invoked anonymous function
like so:
```D
mixin template implement(string typeName, string[] members)
{
mixin(() {
string result = "struct " ~ typeName ~ " {";
foreach (name; members)
{
result ~= "int " ~ name ~ ";";
}
result ~= "}";
return result;
} ());
}
mixin implement!("S", ["x", "y", "z"]);
immutable s = S(x: 3, y: 5, z: 7);
```
You can use your fixed size array append function to try and
improve CTFE performance, but I'd start with straightforward
concatenation, and see if it's actually too slow. In that case,
maybe see if you can reduce it to a self-contained example and
post it on bugzilla as a performance bug.
Re: Why does this mixin fail to compile?
On Monday, 1 July 2024 at 09:25:39 UTC, ryuukk_ wrote:
This simple mixin fails to compile, anyone know why?
```D
mixin implement;
mixin template implement() {
mixin("struct _gen(T) {");
mixin("}");
}
A string mixin must form a complete declaration / statement /
expression / type, so you can't end on an open brace.
Re: Boneheaded question regarding compilation...
On Tuesday, 2 April 2024 at 18:21:58 UTC, Mike Shah wrote: An easier fix may be perhaps to just use 'dub' and install the glfw dependency. In my talk, I did everything from scratch (my preferred way), though I suspect using dub with glfw-d (https://code.dlang.org/packages/glfw-d) may provide less resistance. glfw-d also provides an OpenGL hello world triangle example: https://github.com/dkorpel/glfw-d/tree/master/examples/triangle-gl It uses bindbc-opengl instead of glad to load OpenGL functions.
Re: Using C header libs with importC
On Monday, 8 January 2024 at 21:56:10 UTC, Renato wrote: but I tried exactly that! Which gives a seg fault. Looks like there's a bug with the -H switch: https://issues.dlang.org/show_bug.cgi?id=24326 But that shouldn't be necessary, you should just be able to import the c file. I also tried just importing this little C file, but then no symbols from the h file are found at all. Kind of interesting, as if I just write the code using the library in the C file itself, that works fine. That's weird, I'll see if I can reproduce this.
Re: Compiler analysis fault?
On Wednesday, 20 December 2023 at 11:33:22 UTC, DLearner wrote:
The code below fails to compile with
Error: function `test1.foo` no `return exp;` or `assert(0);`
at end of function
unless the commented-out assert(0) is included.
The compiler basically gives up control flow analysis when
encountering a goto statement or labeled break/continue.
```D
bool foo()
{
while(true)
{
L2:
goto L2;
}
// assert(0);
}
```
Re: Changing behavior of associative array
On Saturday, 16 December 2023 at 21:30:55 UTC, kdevel wrote: If you comment out this line ``` //m[f] = 1; ``` in your main function of your posted code you can catch up with your real programm insofar as you now need a ref parameter here, too. That's because `m[f] = 1` initializes the associative array to something non-null. If you pass a `null` AA to a function which adds things, the caller will still have a null pointers. You can initialize a non-null empty AA like this: ```D uint[Foo] m = new uint[Foo]; ``` Then, `m` can be passed by value and you can make additions or removals which the caller sees, unless you assign a new AA in the function.
Re: struct initializer
On Thursday, 30 November 2023 at 07:21:29 UTC, Dom DiSc wrote:
So, why supporting the (somewhat strange looking) version with
curly backets at all?
It only works in one special place, so is simply overhead to
remember.
Again a superfluous way to do the same - but only under
specific circumstances.
I think a syntax should work either always or never.
The syntax was inherited from C. The 'special place' is called
initialization, and it's special because the target type of the
initializer is known in advance, while normal expression
assignments are analyzed bottom up. Since there is no
`typeof({10, 10})`, struct initializers don't work as expressions.
C99 added Compound literals `(S){.a = 10, .b = 20}`, and with
named arguments you can do the same in D: `S(a: 10, b:20)`, and
since the type name is included, they do work as standalone
expressions.
Walter tried to deprecate the old struct initializer syntax:
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1031.md
But it got some resistance, since {} initializers still have an
advantage when you want to define an array of structs, and don't
want to repeat the (potentially long) struct name for every entry.
Also note that even when {} is removed, there are still other
special cases with initialization, for example with arrays:
```D
void main()
{
short[] a = [3: 10]; // ok
a = [3: 10]; // cannot implicitly convert expression `[3:10]`
of type `int[int]` to `short[]`
}
```
Re: mixin issue
On Wednesday, 29 November 2023 at 13:31:14 UTC, DLearner wrote: it works but doesn't seem correct. You're mixing in an expression that creates an empty function and calls it. What do you want it to do?
Re: How to use ".stringof" to get the value of a variable and not the name of the variable (identifier) itself?
On Monday, 9 October 2023 at 16:33:32 UTC, rempas wrote:
However, in my example, "stringof" returns the character "i"
itself and turns that into a string instead of getting its
actual value (number).
The result of `.stringof` is implementation defined, it can be
used for debugging but don't make your program's semantics depend
on the output of it.
...
...
...That being said, this trick can be used to convert an integer
to string at compile time:
```D
enum itoa(int i) = i.stringof;
static foreach(i; 0 .. 10) {
mixin(create_fn!(itoa!i));
}
```
Technically not reliable, but I don't expect integers to ever get
printed differently than a string of base 10 digits.
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote: Is there a reason it would be difficult to make this not compile? No, except that might result in code breakage.
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 10:55:44 UTC, Quirin Schroll wrote:
What am I missing here?
The duplicate definition check doesn't consider whether a
function is actually unambiguously callable (without e.g. traits
getOverloads), it only prevents creating the same linker symbol
multiple time. So you can even do this:
```D
void f() { }
extern(C) void f() { }
```
But this straight up looks like a bug:
```D
void g() { }
static void g() { } // static doesn't even do anything here
```
Re: dub Fetches Wrong Package Version
On Saturday, 29 July 2023 at 16:47:34 UTC, Ruby The Roobster wrote: Dub refuses to fetch the ~master branch of a package, even when dub.json tells it to. Is there any workaround to this? Delete dub.selections.json, which locks in dependency versions until you explicitly upgrade.
Re: Perspective Projection
On Friday, 28 July 2023 at 16:08:43 UTC, Ruby The Roobster wrote: Everything displays fine (with orthographic projection, of course) if you leave the projection as the identity matrix, but setting it as I have done results in a blank screen. How do you pass the matrix to OpenGL? Be careful that gl3n uses row major matrices, but OpenGL uses column major matrices, so you either need to transpose it yourself, or pass `true` to the `transpose` argument in `glUniformMatrix4fv`.
Re: Syntax for Static Import of User Define Attributes
On Friday, 28 July 2023 at 12:20:05 UTC, Steven Schveighoffer
wrote:
On 7/28/23 8:10 AM, Vijay Nayar wrote:
It might be possible to expand the grammar. It seems very
specific to UDAs, as it doesn't just throw out `Expression` or
whatnot. It probably has to do with the spot that it's in
(declaration).
Yes, parsing arbitrary expressions after an `@` would result in
this:
```D
void f(int x) @att in (x > 0) { }
```
Being parsed as:
```D
void f(int x) @(att in (x > 0)) { }
```
And things like `@3 + 3` don't look like they would be parsed as
`@(3 + 3)`, it looks like `(@3) + 3`.
So the syntax as `@(expression)` to make it clear where the
expression ends. Then there's `@identifier` and
`@identifier(args)` as shorthand for common cases that do look
clear. I recently added `@TemplateSingleArgument` so you can do
`@"abc"` or `@3` as well. Perhaps the syntax can be expanded to
allow `@a.b.c(d)` as well, as well as `@a.b.c!d`, though there's
a risk of the rules getting convoluted.
Re: Syntax for Static Import of User Define Attributes
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
@(vibe.data.serialization.name)("name")
...
}
```
Try:
```D
@(vibe.data.serialization.name("name"))
```
Re: AA vs __gshared
On Thursday, 27 July 2023 at 15:57:51 UTC, IchorDev wrote: The faults happen seemingly at random, and from pretty mundane stuff like `if(auto x = y in z)` that run very often: Are you accessing the AA from multiple threads?
Re: Which D compiler is the most maintained and future-proof? [DMD GDC and LDC]
On Monday, 24 July 2023 at 13:30:27 UTC, cc wrote: Is there any list of known significant "gotchas" with moving to LDC from DMD? Any unexpected surprises to watch out for or be careful for? - DMD has weak linking for all functions by default (mostly as a workaround to several bugs). In LDC, you might get 'duplicate definition' errors when linking D objects that succeeds when compiled with dmd. - DMD supports C opaque struct definitions in headers (though arguably a bug as well) while LDC will complain, see https://github.com/ldc-developers/ldc/issues/3817 Known edge cases of compiler optimization causing different behavior between vendors? LDC can optimize much more aggressively, so if your code has undefined behavior, it's more likely to manifest as a bug with LDC. I had a unittest that succeeded with dmd but failed with `ldc2 -O3` because there was a bitshift larger than 63. DMD didn't care much (it would just do modulo 64), but LDC optimized the function based on the assumption that a parameter could never be 0, which I didn't intend.
Re: Print debug data
On Wednesday, 19 July 2023 at 01:13:23 UTC, Steven Schveighoffer wrote: It's kind of a terrible message, I wish it would change to something more informative. As of https://github.com/dlang/dmd/pull/15430, there's a new message: ``` accessing non-static variable `freeSize` requires an instance of type `Stats` ```
Re: getOverloads order
On Thursday, 13 July 2023 at 11:04:40 UTC, IchorDev wrote: However, the spec doesn't specify that this is how `getOverloads` **must** work; is this guaranteed behaviour but the spec simply omits it? The order is not guaranteed. I don't know why you need a specific order, but perhaps you can sort based on `__traits(getLocation)`.
Re: getOverloads order
On Thursday, 13 July 2023 at 08:03:02 UTC, IchorDev wrote:
I've noticed that `__traits(getOverloads)` always returns the
overloads in lexical order across DMD, LDC, and GDC. Is this
reliable at all?
No. It depends on the order the compiler analyzes the symbols,
which is often lexical order, but it can vary based on static if,
mixin, forward references etc. Here's a counter example:
```D
void f(int x);
mixin("void f(float y);");
void f(char z);
```
Here you get overloads of `f` in the order (x, z, y) instead of
(x, y, z).
Re: Strange behaviour of __traits(allMembers)
On Sunday, 18 June 2023 at 10:21:16 UTC, IchorDev wrote: Whaat why has this not been fixed in the last 4 years! It's now fixed: https://github.com/dlang/dmd/pull/15335
Re: pragma msg field name?
On Tuesday, 27 June 2023 at 05:03:01 UTC, Jonathan M Davis wrote: However, I would point out that getSymbolsByUDA gives you symbols, not strings, whereas pragma(msg, ...) wants a string. For some time now, it accepts any number of objects, which will all be converted to strings and concatenated to form the message. The same applies to `static assert()`.
Re: Problem with dmd-2.104.0 -dip1000 & @safe
On Friday, 9 June 2023 at 04:05:27 UTC, An Pham wrote: Getting with below error for following codes. Look like bug? Filed as https://issues.dlang.org/show_bug.cgi?id=23985 You can work around it by marking parameter `a` as `return scope`
Re: How to deal with interdependent dlang PRs?
On Thursday, 25 May 2023 at 15:37:00 UTC, Quirin Schroll wrote: Is there a process? I can’t be the first one running into this. Doing it in 3 PRs is the process. This is one of the reasons why druntime was merged into dmd's repository. I remember someone saying that if you name the git branches the same, the CI checks out the PR's corresponding branch in other repositories, but I have no experience doing this so I'm not sure it will work.
Re: cast expressions
On Wednesday, 3 May 2023 at 09:03:38 UTC, Dom DiSc wrote: I know, (c) is a constructor call, but for basic types that's the same as (a) isn't it? No, a cast allows for overflow `cast(ubyte) 256`, while the constructor needs an integer that fits. `ubyte(256)` is an error. If t provides a constructor for typeof(x) and x provides opCast to type t, which one is called? When casting, opCast has precedence over a constructor. Does all three forms work if only the constructor or only the opCast is provided? A constructor call will not be lowered to opCast, but a cast can be lowered to a constructor call. And is (b) always equivalent to (a)? C style cast syntax is not allowed in D.
Re: -preview=in deprecation warning
On Thursday, 20 April 2023 at 09:14:48 UTC, Jack Applegame wrote:
Can anyone help me get rid of this depreciation?
Annotate `getFoo` with `return scope`:
```d
struct Foo {
string foo;
string getFoo() return scope const @safe { return foo; }
}
Re: Returning a reference to be manipulated
On Saturday, 15 April 2023 at 21:00:01 UTC, kdevel wrote: On Saturday, 15 April 2023 at 15:50:18 UTC, Dennis wrote: [...] care about the type / mutability of the pointer. Returning `i`'s address in a long does not trigger the escape detector: It doesn't care about the type of pointer, but it does care about whether the type is/has a pointer in the first place. `T*`, `T[]`, `K[V]` (Associative arrays), `class`, `function`, `delegate` are pointers. Static arrays and structs depend on what they contain. Basic types such as `long` are not pointers, so lifetime checking doesn't apply.
Re: Returning a reference to be manipulated
On Saturday, 15 April 2023 at 14:33:52 UTC, kdevel wrote:
Does that make sense?
Whether it makes sense is subjective, but it is by design. Escape
analysis considers every pointer the same, it doesn't care about
the type / mutability of the pointer. In `@system` / `@trusted`
code, you could coerce `i` to become a string and return it:
```D
string foo(string s, return ref int i)
{
return (cast(immutable char*) )[0..4];
}
```
Re: Returning a reference to be manipulated
On Saturday, 15 April 2023 at 14:10:57 UTC, Dennis wrote: This adds complexity, just to add some 'intermediate' safety between `@system` and `@safe` in a few cases. It's better to keep the rules simple and consistent. To quote my past self: There used to be different rules for lifetime errors in all of these: - explicit `@system` functions - `@system` by default functions (yes, [they were special](https://issues.dlang.org/show_bug.cgi?id=19873)) - inferred functions - `@safe` functions - `@trusted` functions It was really complex and confusing, and I've worked on simplifying it such that all lifetime errors are safety violations like any other. The only exception is directly returning a dangling pointer to a stack variable, which is just an error even in @system code ([issue 19873](https://issues.dlang.org/show_bug.cgi?id=19873)). I don't want to go back to more special cases, especially with the dip1000 by default transition which is complex enough as is. https://forum.dlang.org/post/nzotevvzvbpqscfxs...@forum.dlang.org
Re: Returning a reference to be manipulated
On Saturday, 15 April 2023 at 13:20:09 UTC, kdevel wrote: Under which circumstances is it a mistake to insert the `return` at the indicated position? If there are none why can't it be done implicitly (automatically)? It could be done in the easy example you posted, but generalizing it is harder. When importing a module, the compiler currently doesn't need to analyze function bodies to get the signature of regular (non-auto/template) functions, which would have to change. Programmers can also currently rely on the fact that the signature they see is the signature they get, but not any longer. The identity function is really simple, but as soon as control flow (if-statements) come into play, the annotations and their inference become a conservative approximation, which might give false positives in `@system` code. There would need to be a second system, one which assumes the best instead of assuming the worst. This adds complexity, just to add some 'intermediate' safety between `@system` and `@safe` in a few cases. It's better to keep the rules simple and consistent.
Re: Returning a reference to be manipulated
On Friday, 14 April 2023 at 10:31:58 UTC, kdevel wrote:
But in fact it is returned unless it is `return ref`.
When using `return ref`, `return scope`, `scope` etc., you should
be using the latest compiler and annotate functions you want
checked with `@safe`. In previous versions, the compiler would
often conflate `return ref` and `return scope`, and it was also
inconsistent in whether it would do checks in `@safe`, `@system`,
and even 'default/unannotated' functions.
Now, it is more consistent, performing checks in `@safe` code
only.
I don't get it! Is there any legitimate use of returning a ref
such that it outlives the matching argument's lifetime? If not:
Isn't this `return ref` completely redundant?
The annotation is needed because the compiler can't always figure
out what you're doing with a `ref` parameter:
```D
ref int mysteryFunc(ref int x) @safe; // external implementation
ref int escape() @safe
{
int local; // allocated on stack frame, should not escape
this function
return mysteryFunc(local); // is this safe?
}
```
Is this indeed `@safe`? It is, provided that `mysteryFunc`
doesn't return its parameter `x`. It can be implemented like this
for example:
```D
ref int mysteryFunc(ref int x) @safe
{
x++;
return *(new int);
}
```
But it wouldn't be safe if `x` were returned, so the compiler
must know about that when it happens, hence `return ref`:
```D
ref int mysteryFunc(return ref int x) @safe
{
return x;
}
```
Now the compiler can catch that `return mysteryFunc(local)` is
unsafe. Note that if `mysteryFunc` is a template function, nested
function, or returns `auto`, then the compiler infers attributes
automatically, including `return ref`. Then you can still write
it as `mysteryFunc(ref int x)` and it will automatically be
treated as `return ref`.
Re: Is this code correct?
On Friday, 31 March 2023 at 13:11:58 UTC, z wrote: I've tried to search before but was only able to find articles for 3D triangles, and documentation for OpenGL, which i don't use. The first function you posted takes a 3D triangle as input, so I assumed you're working in 3D. What are you working on? Determines if a triangle is visible. You haven't defined what 'visible' means for a geometric triangle.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Friday, 31 March 2023 at 16:26:36 UTC, ryuukk_ wrote: That the same bad advice as telling people to "embrace OOP and multiple inheritance" and all the Java BS "just put your variable into a class and make it static, and then have your singleton to access your static variables" I agree that singletons aren't any better than global variables. The better way is to pass state through function parameters.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Friday, 31 March 2023 at 15:52:21 UTC, ryuukk_ wrote: the point i bring is ``__gshared`` is ugly, so we want an ugly language? Good code shouldn't look ugly, but global mutable variables are bad, so it's appropriate that they look ugly. You can still put a single `__gshared:` at the top of your module.
Re: Is this code correct?
On Thursday, 30 March 2023 at 10:29:25 UTC, z wrote: Is this code correct or logically sound? You need to be exact on what 'correct' is. The comment above `triangleFacesCamera` says: Indicates wether a triangle faces an imaginary view point. There's no view point / camera position defined anywhere in your code. Instead, all it's doing is comparing the angle of one triangle side (A->B) with another (B->C) in the XZ plane. This suggests you want to know the triangle winding order: clockwise or counter clockwise. If you search for "triangle winding order" you'll find simple and correct ways to do that. Your code needlessly computes angles, only considers the XZ plane, and doesn't compare the angles correctly. r2 -= r1; return r2 > 0; You need to wrap (r2 - r1) into [-τ/2, τ/2] range, then you can compare with 0.
Re: The Phobos Put
On Wednesday, 29 March 2023 at 11:10:42 UTC, Salih Dincer wrote: Why does my `put` work but the Phobos `put` doesn't work with a slice? Your `put` doesn't take `range` by `ref`, so it allows you to pass an rvalue. Consequently, it doesn't advance the range from the callers perspective.
Re: Problem with ImportC example?
On Tuesday, 17 January 2023 at 11:16:25 UTC, DLearner wrote: ``` C:\Users\SoftDev\Documents\BDM\D\ImportC>dmd ex01.c ex01.c(1): Error: C preprocessor directive `#include` is not supported ex01.c(1): Error: no type for declarator before `#` ex01.c(5): Error: no type for declarator before `return` ex01.c(6): Error: no type for declarator before `}` ``` What is your `dmd --version`? I suspect you have a version where you still have to manually pre-process the .c file, instead of a more recent version which invokes the pre-processor itself.
Re: Unittests on a module
On Friday, 13 January 2023 at 19:07:46 UTC, DLearner wrote:
Is this intended?
It is by design, though opinions differ on whether it's a good
design.
It's not a problem to add temporary
```
void main() {
}
```
to the bottom of the module,
You can add the `-main` flag to make dmd automatically add such
an empty main function when there isn't a `main` already.
Re: Should importC fail on invalid C code?
On Friday, 13 January 2023 at 12:50:44 UTC, kdevel wrote: Should importC fail on invalid C code? In general, no. The purpose is to build / interface with existing C code, not to develop new C code with it. ImportC also has its own extensions by borrowing D features such as __import, CTFE, and forward references. A strict C compiler would reject those.
Re: Why does the importC example not compile?
On Friday, 13 January 2023 at 12:33:28 UTC, kdevel wrote: What must be added or changed in order to test every example which is intended to produce an executable? Support for separate compilation / ImportC would need to be added to dspec_tester: https://github.com/dlang/dlang.org/blob/master/tools/dspec_tester.d
Re: Why does the importC example not compile?
Thanks for reporting this. PR: https://github.com/dlang/dlang.org/pull/3489 On Friday, 13 January 2023 at 11:10:23 UTC, kdevel wrote: I would have expected that each and every piece of code in the documentation is automatically compiled with any new compiler release. Individual D snippets can be tested when given the right DDoc macro, such as `SPEC_RUNNABLE_EXAMPLE_RUN` or `SPEC_RUNNABLE_EXAMPLE_FAIL`. (Thanks to Nick Treleaven for adding it to many examples that didn't have it before!) I don't think there's a way to test examples of separate compilation in the spec currently.
Re: How Can i see associative array implement , is where has pseudocode write in Dlang?
On Thursday, 29 December 2022 at 11:24:38 UTC, lil wrote: How Can i see associative array implement , is where has pseudocode write in Dlang? If you're asking for the implementation of Associative Arrays, you can find that in druntime in the `rt.aaA` module: https://github.com/dlang/dmd/blob/master/druntime/src/rt/aaA.d There's no pseudo code of it, but it's a pretty standard hash table.
Re: How often I should be using const? Is it useless/overrated?
On Friday, 18 November 2022 at 11:51:42 UTC, thebluepandabear wrote: A question I have been thinking about whilst using D is how often I should be using const. This should be a good read for you: [Is there any real reason to use "const"?](https://forum.dlang.org/post/dkkxcibwdsndbckon...@forum.dlang.org)
Re: Making sense out of scope and function calls
On Sunday, 13 November 2022 at 19:06:40 UTC, 0xEAB wrote: Why does only the latter sample compile? The former leads to the following warning: Can you please provide a full example? I'm missing the definitions of _headers, hstring, values, and I suspect there's at least one `@safe` annotation somewhere.
Re: dmd as a library
On Tuesday, 8 November 2022 at 05:48:54 UTC, vushu wrote: Ah thanks that's nice to have some examples. Here's an example of tools using dmd as a library: https://github.com/jacob-carlborg/dlp
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote: 3. I'm currently having a bug on my API module that every duplicated file name, even when located at different directories(modules), are generating duplicate symbol. The major problem is that this is currently undebuggable, as the MSVC Linker does not show the full directory of the libraries/object files that caused this clash, not even the symbol! Do you have a (reduced) example of this?
Re: how to benchmark pure functions?
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote:
How can I prevent the compiler from removing the code I want to
measure?
With many C compilers, you can use volatile assembly blocks for
that. With LDC -O3, a regular assembly block also does the trick
currently:
```D
void main()
{
import std.datetime.stopwatch;
import std.stdio: write, writeln, writef, writefln;
import std.conv : to;
void f0() {}
void f1()
{
foreach(i; 0..4_000_000)
{
// nothing, loop gets optimized out
}
}
void f2()
{
foreach(i; 0..4_000_000)
{
// defeat optimizations
asm @safe pure nothrow @nogc {}
}
}
auto r = benchmark!(f0, f1, f2)(1);
writeln(r[0]); // 4 μs
writeln(r[1]); // 4 μs
writeln(r[2]); // 1 ms
}
```
Re: How to workaround assignment not allowed in a condition?
On Wednesday, 12 October 2022 at 10:09:31 UTC, Steven
Schveighoffer wrote:
I'm actually very surprised that just wrapping the statement in
an == expression doesn't do the trick, what is the possible
logic behind outlawing that?
I looked into it, there are actually two different places where
dmd files the very same error:
```D
void main()
{
int x;
// Directly in loop conditions
if (x = 3) {}
while (x = 3) {}
for (; x = 3; ) {}
// when an assignment is implicitly cast to a boolean
bool b = !(x = 3);
assert(x = 3);
true && (x = 3);
}
```
Wrapping in `==` actually does do the trick, but you need to get
rid of the `!` operator. So instead of `while(!(x=3) == true)`
make it `while ((x=3) == false)`
Re: How to workaround assignment not allowed in a condition?
On Wednesday, 12 October 2022 at 02:15:55 UTC, Steven
Schveighoffer wrote:
Porting some C code to D
This results in an error:
I had the same issue, where the pattern was this:
```C
void f()
{
int err;
if (err = some_api_call()) {
printCode(err);
return;
}
if (err = some_other_api_call()) {
printCode(err);
return;
}
}
```
I would either declare the variable in the if statement:
```D
void f()
{
if (auto err = some_api_call()) {
printCode(err);
return;
}
if (auto err = some_other_api_call()) {
printCode(err);
return;
}
}
```
Or take the assignment out of the condition:
```D
void f()
{
int err;
err = some_api_call();
if (err) {
printCode(err);
return;
}
err = some_other_api_call();
if (err) {
printCode(err);
return;
}
}
```
I haven't seen it used in a while condition yet, perhaps you can
transform that into a for loop?
Re: Convert array of simple structs, to C array of values
On Monday, 3 October 2022 at 07:45:47 UTC, Chris Katko wrote: I know there's gotta be some simple one liner function in D, but I can't think of it. I don't know if you're looking for type safety, but you can just do `cast(float*) values.ptr;` or `cast(float[]) values[]`.
Re: can not take const struct member address at CTFE , is this a bug?
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote: I hope we have github bugs. It's being worked on. Please help me create a bug report if who has free time and bugs account. Here you go: https://issues.dlang.org/show_bug.cgi?id=23336
Re: need help to translate C into D
On Tuesday, 13 September 2022 at 11:03:30 UTC, test123 wrote: and upb_MiniTable_Enum can include a lot diff types. (for example mixed diff size upb_MiniTable_Enum) I think you'll need a `void*` array then, since pointers to different structs can all implicitly convert to `void*`.
Re: need help to translate C into D
On Tuesday, 13 September 2022 at 10:45:03 UTC, test123 wrote: Is there a way to init the __gshared fixed length upb_MiniTable_Enum array ? I don't think so. You could leave your array typed as `validate_KnownRegex_enum_init_type` and access it through a function that casts it to `upb_MiniTable_Enum`. Side node, you can use `immutable` instead of `__gshared const`, it amounts to the same for global variables.
Re: need help to translate C into D
On Tuesday, 13 September 2022 at 09:43:46 UTC, test123 wrote:
This will not work since the C have no array like D.
You can use a 0-size static array:
```D
struct mystruct {
uint32_t mask_limit; // Limit enum value that can be tested
with mask.
uint32_t value_count; // Number of values after the bitfield.
uint32_t[0] data; // Bitmask + enumerated values follow.
}
```
Then you have to index with `mystructVar.data.ptr[i]` to avoid
bounds checking.
Re: Validate static asserts
On Friday, 9 September 2022 at 16:41:54 UTC, Andrey Zherikov
wrote:
What's about new `compileOutput` trait that returns compiler
output?
```d
static assert(__traits(compileOutput, { }) ==
"message");
```
As a compiler dev, that sounds terrifying. It would make
basically every change to dmd a breaking change.
Re: Reference to an unresolved external symbol
On Wednesday, 7 September 2022 at 10:14:22 UTC, Injeckt wrote: I guess you right. But I don't know how i gonna link libs when I'm using "dmd main.d". Another way is to add this to your code: ```D pragma(lib, "User32"); ```
Re: Compile time int to string conversion in BetterC
On Wednesday, 17 August 2022 at 08:44:30 UTC, Ogi wrote: Maybe I’m missing something? I had the same problem, and came up with the following trick: ```D enum itoa(int i) = i.stringof; enum major = 3; enum minor = 2; enum patch = 1; enum versionString = itoa!major ~ "." ~ itoa!minor ~ "." ~ itoa!patch; static assert(versionString == "3.2.1"); ``` Now I need to warn you that the output of `stringof` is technically implementation defined per the specification, so you shouldn't rely on it. In practice [this doesn't stop people](https://github.com/libmir/mir-algorithm/pull/422), and I don't think integers will ever not be printed as a string of base 10 digits.
Re: Programs in D are huge
On Tuesday, 16 August 2022 at 08:25:18 UTC, Diego wrote: It seams huge in my opinion for an empty program What are the best practices to reduce the size? The problem is that the druntime, the run time library needed to support many D features, is large and linked in its entirety by default. The linker could strip unused functions, but even in an empty program, a lot is done before `main` that pulls in most of it: - initializing floating point settings, signal handlers, stdout and stderr - parsing --DRT command line options for configuring the Garbage Collector - running module constructors / unit tests There is a goal to make druntime more 'pay as you go' so these things only happen when they're needed, but progress is slow. In the mean time, if you can live without a lot of D features that require the runtime, you can use `-betterC`: https://dlang.org/spec/betterc.html With the LDC2 compiler, you can use `--link-defaultlib-shared`, so your program dynamically links with the run time library. This doesn't help for a single D program, but multiple D programs can reuse a single shared library. Finally, you could look at customized versions of the runtime, such as Light Weight D Runtime: https://github.com/hmmdyl/LWDR
Re: Some user-made C functions and their D equivalents
On Wednesday, 27 July 2022 at 18:19:34 UTC, pascal111 wrote: The library link: https://github.com/pascal111-fra/turbo-c-programs/blob/main/COLLECT2.H It would help if the functions had a comment explaining what they're supposed to do, but it looks like most of them are string functions. In D, you can concatenate strings with the `~` operator, and utility functions like `strip` and `replace` are in the `std.string` module: https://dlang.org/phobos/std_string.html I also think you defined the equivalent of these functions: ```D import std.algorithm: swap; import std.math: sgn, trunc; ```
Re: BetterC Name Mangling Linker Errors
On Wednesday, 27 July 2022 at 12:26:59 UTC, MyNameHere wrote:
```d
void Main(void* Instance)
{
WNDCLASSEXA WindowClass;
```
This is equivalent to `WNDCLASSEXA WindowClass =
WNDCLASSEXA.init;`
If the struct's fields all initialize to 0, the compiler would
simply set the variable's bytes to 0, but the definition in
druntime gives fields with non-zero default value:
```D
struct WNDCLASSEXA {
UINT cbSize = WNDCLASSEXA.sizeof; // <-- non zero init
UINT style;
WNDPROC lpfnWndProc;
int cbClsExtra;
int cbWndExtra;
HINSTANCE hInstance;
HICON hIcon;
HCURSOR hCursor;
HBRUSHhbrBackground;
LPCSTRlpszMenuName;
LPCSTRlpszClassName;
HICON hIconSm;
}
```
Because of this, the compiler defines an 'init symbol' in
druntime that gets copied into your variable to initialize it.
Because druntime isn't linked when using BetterC, the linker
fails to find the init symbol.
I think removing the default initialization will fix it:
```D
WNDCLASSEXA WindowClass = void;
```
Re: Expanding CTFE code during compilation
On Wednesday, 20 July 2022 at 00:33:06 UTC, Azi Hassan wrote: Where did you find it though ? I checked dmd --help and man dmd before making this thread, but to no avail. It was implemented as an internal debugging tool, not a documented feature: https://github.com/dlang/dmd/pull/6556 It turned out to be useful for users as well though, and got exposure through the "AST" button on https://run.dlang.io/ Maybe it's time to document it, currently there's only this: https://wiki.dlang.org/DMD_Source_Guide#View_emitted_templates_instances_and_string.2Fmixins
Re: Expanding CTFE code during compilation
On Tuesday, 19 July 2022 at 21:43:01 UTC, Azi Hassan wrote:
I'm wondering if the offers has the option of executing the
parts that can be evaluated at compile time and then replacing
them with the result of this evaluation.
Try the `-vcg-ast` flag:
```D
import object;
import std;
void main()
{
enum int x = 24;
writeln(24);
return 0;
}
// ... and a bunch of template instances
```
Re: Enforce not null at compile time?
On Monday, 20 June 2022 at 17:48:48 UTC, Antonio wrote: Is there any way to specify that a variable, member or parameter can't be null? Depends on the type. Basic types can't be null. Pointers and classes can always be `null`, though you could wrap them in a custom library type that doesn't allow them to be `null`. Dynamic arrays and associative arrays can be null, but it's equivalent to them being empty, so you can still use them like normal. You can pass a struct as a `ref` parameter, which passes it by reference but it's still typed as a plain struct, so it can't be `null`.
Re: Whats the proper way to write a Range next function
On Wednesday, 15 June 2022 at 13:52:24 UTC, Christian Köstlin wrote: looks like there should be tons of annotations/attributes on it. Because you have a template function, most attributes will be inferred based on the Range type. `const` is not inferred, but `popFront` mutates so it doesn't apply in your case. `@property` is not inferred either, but the spec says "Using property functions is not recommended until the definition is more certain and implementation more mature."
Re: C-like static array size inference - how?
On Tuesday, 7 June 2022 at 00:20:31 UTC, Ali Çehreli wrote: > it's complaining about TypeInfo being absent. What an unfortunate error message! Trying writeln() causes equally weird error messages. Walter just improved it! https://github.com/dlang/dmd/pull/14181 Perhaps try a [nightly build](https://github.com/dlang/dmd/releases/tag/nightly)
Re: Unexplainable behaviour with direct struct assignment.
On Wednesday, 18 May 2022 at 20:05:05 UTC, HuskyNator wrote: This will print: ``` 0 50 nan ``` Which compiler and flags are you using? For me it just prints 50, you might be stumbling on some (old) bugs in the DMD backend with floating point registers. Examples of such bugs are: https://issues.dlang.org/show_bug.cgi?id=18573 https://issues.dlang.org/show_bug.cgi?id=22163
Re: Including C sources in a DUB project
On Tuesday, 10 May 2022 at 20:50:12 UTC, Alexander Zhirov wrote: And if there are two compilers in the system - `dmd` and `ldc`, which compiler chooses `dub.json`? It depends on whether your DMD or LDC installation comes first in your PATH environment variable. Both ship with a `dub` executable that uses their compiler as default. And how do I specify the specific compiler I want? On the command line you can use the `--compiler=dmd` flag. You can't specify this in the dub.json, since your project is supposed to be compiler agnostic.
Re: Including C sources in a DUB project
On Tuesday, 10 May 2022 at 17:19:23 UTC, jmh530 wrote: It would be nice if dub included a directory of example configurations for common issues like this. It has an example directory: https://github.com/dlang/dub/tree/master/examples If your configuration is missing, you could make a Pull Request to add it.
Re: dip1000 return scope dmd v 2.100
On Friday, 6 May 2022 at 09:24:06 UTC, vit wrote:
It look like examples at page
https://dlang.org/spec/function.html#ref-return-scope-parameters are no longer relevant.
They were recently updated to match the implementation in 2.100.
What difference are between `return scope`, `scope return` and
`return`?
`return scope` means pointer members (such `this.ptr`, `C.ptr`)
may not escape the function, unless they are returned. If you
call `test()` on a `scope` variable, the return value will be a
scope pointer.
`scope return` on a struct member is `scope` + `return ref`,
meaning pointer members may not escape the function (the `scope`
part), but you can return a reference to the struct member itself
(``, the `return ref` part). If you call `test()` on a
local variable (`scope` or not), the return value will be a scope
pointer.
Just `return` allows you to return a reference to the struct
member itself (``), and also to escape pointer members
(`this.ptr`) since there is no `scope`. However, that means you
can't call `test` on `scope` variables.
```
int* test() scope return{
return // Error: returning `` escapes a
reference to parameter `this`
}
}
```
I think you're using an older DMD version, the error should be
gone in 2.100
Why void* ptr in struct change effect of scope return ?
`scope` is ignored when the struct has no pointers, and before
2.100, the meaning of `return` + `scope` on `ref` parameters was
very inconsistent.
Re: DMD failed with exit code -1073741819
On Tuesday, 3 May 2022 at 18:22:49 UTC, jmh530 wrote: Does anyone have any idea what causes these types of errors? Sounds like a stack overflow, maybe your code has a complex/recursive part that makes DMD's call stack very deep.
Re: T... args!
On Friday, 29 April 2022 at 15:13:08 UTC, Tejas wrote: It's not a keyword yet it's recognised specially by the compiler... What? It's not really recognized by the compiler, there's a little bit of magic to print `string` in outputted D code (e.g. error messages) instead of `immutable(char)[]`, but that's it.
Re: Is T.init allowed?
On Friday, 29 April 2022 at 11:30:49 UTC, Andrey Zherikov wrote: Is it a compiler issue so this shouldn't be allowed? Members called `init` are in the process of being deprecated, see: https://github.com/dlang/dmd/pull/12512
Re: CTFE and BetterC compatibility
On Thursday, 28 April 2022 at 12:10:44 UTC, bauss wrote: On Wednesday, 27 April 2022 at 15:40:49 UTC, Adam D Ruppe wrote: but this got killed due to internal D politics. A pity. A tale as old as time itself In this case, it was actually a trailing whitespace in the changelog entry making the test suite fail, but the PR author ceased activity before fixing it and now it has merge conflicts. https://github.com/dlang/dmd/pull/11014#discussion_r427108067
Re: How do I get the screen resolution?
On Thursday, 28 April 2022 at 11:22:15 UTC, Alexander Zhirov wrote: Are there any methods to get the screen resolution? Example with GLFW: https://github.com/dkorpel/glfw-d/blob/7a1eec60d427617c098d0e54a26cba796956a976/examples/empty-window/app.d#L118 Note that there can be multiple monitors, but you can use `glfwGetPrimaryMonitor()` to find the main one.
Re: Library for image editing and text insertion
On Wednesday, 27 April 2022 at 07:42:31 UTC, Alexander Zhirov wrote: ```d ~/programming/d/pic $ dmd app.d ``` Try passing the `-i` flag: `dmd -i app.d`. This way, imported modules are actually compiled and linked too. Currently it looks like you import arsd, but then don't link the library, so it complains about undefined references to functions in arsd.
Re: unexpected noreturn behavior
On Thursday, 21 April 2022 at 12:41:08 UTC, WebFreak001 wrote:
which I think is a little bug-prone, but at least that would
solve my issues.
What issue do you have with it returning `true`? Note that this
compiles:
```D
@safe:
import std.sumtype;
void main()
{
SumType!(int, string) s = assert(0);
}
```
Re: Install D lang on Windows 10 : an installation step by step tutorial made by a beginner who loves D !
On Monday, 18 April 2022 at 08:22:43 UTC, SMAOLAB wrote: I tried to install D on a Windows 10 but encountered some difficulties (even though I was reading the official D langage tutorial available on the official website). What went wrong when you used the DMD installer? Installing Visual Studio should not be necessary, since DMD ships with the lld linker and MinGW Windows import libraries. If it doesn't work out of the box, it should be fixed. Nevertheless, thanks for writing the detailed instructions. Have a nice reading and don't hesitate to send me your comments, I will improve the document... I don't see the guide (explicitly) installing git, but I recall dub needing it to install packages. Is that covered?
Re: scope variable `b` assigned to `a` with longer lifetime (-dip1000)
On Saturday, 9 April 2022 at 10:39:33 UTC, vit wrote:
Why doesn't this code compile?
`proxySwap1` is lying about its attributes. It says `rhs` is
`scope`, but it escapes by assignment `this.ptr = rhs.ptr;`. The
compiler doesn't raise an error because it's marked `@trusted`.
`proxySwap2` is simply a template function wrapping `proxySwap1`,
attributes are inferred based on the signature you specified for
`proxySwap1` (even if it's wrong).
`proxySwap3` is a template function, so the compiler infers `rhs`
to be `return scope`. While a `@trusted` function allows you to
escape `scope` variables, the compiler will still try to infer
`scope`, `return scope` or `return ref` on its parameters as far
as it can, and that can spawn errors in its `@safe` callers.
Swapping `scope` variables is not something you can do in `@safe`
code with dip1000's current design, because of this:
```D
void main() @safe {
scope Foo a;
{
int x;
scope Foo b = Foo();
a.proxySwap3(b); // scope variable `b` assigned to `a` with
longer lifetime
}
// a is now a dangling pointer
}
```
Re: Check if Key exists in Associative Array using D language.
On Tuesday, 5 April 2022 at 11:26:27 UTC, BoQsc wrote: I'd like to know if there is similar function: that can check if a **key** inside a [Associative Array][2] can be found. You can use the `in` operator for that: https://dlang.org/spec/hash-map.html#testing_membership
Re: Embarrassed to ask this question because it seems so trivial but genuinely curious...
On Thursday, 27 January 2022 at 17:42:09 UTC, WhatMeWorry wrote:
So I guess my question is, is this just a matter of esthetics
or is some more nuanced goal at work here?
It doesn't matter much for constructors, but in general, the
problem with placing qualifiers in front is that it looks
confusing:
```D
struct S
{
immutable int[] f()
{
return [];
}
}
```
This reads as if it returns an `immutable(int[])`, but it
doesn't, the `immutable` means that it can only be called on
`immutable` instances of `S`.
Re: How to create a function that behaves like std.stdio.writeln but prepends output with __FILE__:_LINE_
On Tuesday, 25 January 2022 at 12:11:01 UTC, JG wrote:
Any ideas how one can achieve what is written in the subject
line?
```D
void f(T...)(auto ref T args, string file = __FILE__, int line =
__LINE__)
{
writeln(file, ":", line, ": ", args);
}
```
Re: Returning value by ref does not create a ref. Is this intentional?
On Wednesday, 5 January 2022 at 05:38:45 UTC, Tejas wrote: The entire reason I wanted to get a `ref` was so that I can avoid the `*` :( I don't know what the real code behind the reduced example is, but maybe you can structure your code such that the subsequent modification `c = 10` happens in its own function. Then you can pass the result of `func(a)` to that function by `ref`.
Re: Thread exits immediately with no reason.
On Tuesday, 21 December 2021 at 07:08:53 UTC, bauss wrote: It should at the very least warn people about functions that may throw errors. What is "It"? I was looking to make a spec PR, but it already says here: https://dlang.org/spec/function.html#nothrow-functions Nothrow functions can only throw exceptions derived from class Error.
Re: Attributes (lexical)
On Thursday, 25 November 2021 at 12:09:55 UTC, Dennis wrote: This should also be fixed in the spec. Filed as: Issue 22543 - [spec] grammar blocks use unspecified notation: https://issues.dlang.org/show_bug.cgi?id=22543 Issue 22544 - [spec] C++ and Objective-C are not single tokens https://issues.dlang.org/show_bug.cgi?id=22544
Re: Attributes (lexical)
On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
Well:
```
#line IntegerLiteral Filespec? EndOfLine
```
Having EndOfLine at the end means for me that there are no
other EOLs between, otherwise this syntax should pass but it's
not (DMD last):
```d
#line 12
"source.d"
```
The lexical grammar section starts with:
The source text is decoded from its source representation into
Unicode Characters. The Characters are further divided into:
WhiteSpace, EndOfLine, Comments, SpecialTokenSequences, and
Tokens, with the source terminated by an EndOfFile.
What it's failing to mention is how in the lexical grammar rules,
spaces denote 'immediate concatenation' of the characters/rules
before and after it, e.g.:
```
DecimalDigits:
DecimalDigit
DecimalDigit DecimalDigits
```
`3 1 4` is not a single `IntegerLiteral`, it needs to be `314`.
Now in the parsing grammar, it should mention that spaces denote
immediate concatenation of *Tokens*, with arbitrary *Comments*
and *WhiteSpace* inbetween. So the rule:
```
AtAttribute:
@ nogc
```
Means: an @ token, followed by arbitrary comments and whitespace,
followed by an identifier token that equals "nogc". That explains
your first example.
Regarding this lexical rule:
```
#line IntegerLiteral Filespec? EndOfLine
```
This is wrong already from a lexical standpoint, it would suggest
a SpecialTokenSequence looks like this:
```
#line10"file"
```
The implementation actually looks for a # token, skips
*WhiteSpace* and *Comment*s, looks for an identifier token
("line"), and then it goes into a custom loop that allows
separation by *WhiteSpace* but not *Comment*, and also the first
'\n' will be assumed to be the final *EndOfLine*, which is why
this fails:
```
#line 12
"source.d"
```
It thinks it's done after "12".
In conclusion the specification should:
- define the notation used in lexical / parsing grammar blocks
- clearly distinguish lexical / parsing blocks
- fix up the `SpecialTokenSequence` definition (and maybe change
dmd as well)
By the way, the parsing grammar defines:
```
LinkageType:
C
C++
D
Windows
System
Objective-C
```
C++ and Objective-C cannot be single tokens currently, so they
are actually 2/3, which is why these are allowed:
```D
extern(C
++)
void f() {}
extern(Objective
-
C)
void g() {}
```
This should also be fixed in the spec.
I am not asking this questions out of thin air, I am trying to
write a conforming lexer and this is one of the ambiguities.
That's cool! Are you writing an editor plugin?
Re: Attributes (lexical)
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote: Also, this works also for #line, even if the specification tells us that all tokens must be on the same line Where does it say that?
Re: What is D's "__debugbreak()" equivalent?
On Wednesday, 27 October 2021 at 16:54:49 UTC, Simon wrote:
What is the equivalent in D?
With LDC, you have:
```D
import ldc.intrinsics: llvm_debugtrap;
```
Combining that with previous answers, you can make something like
this:
```D
void debugbreak() nothrow @nogc @trusted {
version(D_InlineAsm_X86_64) {
asm nothrow @nogc {
int 3;
}
} else version(LDC) {
import ldc.intrinsics: llvm_debugtrap;
llvm_debugtrap();
} else {
assert(0); // No `breakPoint` for this compiler configuration
}
}
```
Re: Unexpected path of execution
On Tuesday, 19 October 2021 at 16:20:39 UTC, Charles Hixson wrote: core.exception.RangeError@source/freqs.d(32): Range violation ??:? _d_arrayboundsp [0x56041325a70d] ??:? _Dmain [0x560413233beb] DMD64 D Compiler v2.097.2 By the way, if you upgrade to 2.098.0, you get a better error message for out of bounds array access.
Re: Obtaining type and value of a variable named in another variable
On Saturday, 16 October 2021 at 19:28:04 UTC, DLearner wrote: How does one obtain from strVar: 1. The type of fooVar; `typeof(mixin(strVar))` 2. The value of fooVar? `mixin(strVar)`
Re: __traits(compiles) is true with warnings as errors
On Thursday, 14 October 2021 at 11:08:24 UTC, bauss wrote: What could be useful is a new trait (to not break existing code) like __traits(warning, ...) which does the same as __traits(compiles) but also checks whether the arguments would cause a warning by the compiler. N! Warnings suck. Errors are fine, nothing is fine, a big bag of unspecified 'maybes' that are put on either side depending on the user is not. Unfortunately, dub makes warnings into errors by default, but you can use `buildRequirements "silenceWarnings"` or `buildRequirements "allowWarnings"` to mitigate it. If implicit float truncation is really error prone, it should be deprecated. Otherwise the compiler should shut up about it.
Re: avoid codegen pass
On Saturday, 2 October 2021 at 16:57:48 UTC, max haughton wrote: Do you have optimizations turned on? i.e. are you compiling with -O by accident? Not needed, it's declared: ```D pragma(inline, true) @property _timezone() @safe const pure nothrow @nogc ``` DMD does inlining in the frontend, and without the `-inline` flag it still inlines functions when requested by `pragma(inline, true)`. That's why you see it logged even without codegen or `-inline`. That's not what causes the long compile time though, `dmd -v` logs passes before doing them, not after, so it's the semantic3 before the inline pass that's taking all the time.
Re: How can we view source code that has been generated (say via "static foreach") ?
On Wednesday, 15 September 2021 at 19:59:43 UTC, james.p.leblanc wrote: However, with various combinations of templates, UDAs, and mixins it has not been easy. Apart from -mixin, there's also the undocumented -vcg-ast switch that prints the AST before code generation, showing instantiated templates and unrolled static foreach loops.
Re: Development of the foundation of a programming language
On Monday, 13 September 2021 at 03:21:37 UTC, leikang wrote: Are there any recommended books or videos to learn about the principles of compilation? What else should I learn besides the principles of compilation? Check out this video: [DConf 2016 Day 2 Keynote: Spelunking D Compiler Internals -- Walter Bright](https://www.youtube.com/watch?v=bNJhtKPugSQ) Just browsing [dmd's source code](https://github.com/dlang/dmd/tree/master/src/dmd#readme) and watching [dmd's Pull Request queue](https://github.com/dlang/dmd/pulls) is a good way to get familiar with the code and see what a bug fix looks like. Try to start with something small, like error message improvements or [refactorings listed in the contributing guide](https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md#dmd-best-practices). If you have any questions along the way, just ask them.
Re: Phobos Unittest
On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw wrote: Yes, but they are lexed and parsed, right? Right, but that's the case regardless of `version(StdUnittest)`.
Re: C to D convertor
On Saturday, 21 August 2021 at 08:14:22 UTC, Виталий Фадеев wrote: Any more ? CPP2D https://github.com/lhamot/CPP2D
Re: Union member positions?
On Tuesday, 17 August 2021 at 13:46:22 UTC, z wrote:
Is it possible to set a "position" on a union member?
You can use anonymous `struct` and `union` blocks.
```D
union UnionExample{
uint EAX;
struct {
//upper
union {
ushort EAHX;
struct {
ubyte EAHH;
ubyte EAHL;
}
}
//lower
union {
ushort EALX;
struct {
ubyte EALH;
ubyte EALL;
}
}
}
}
```
Re: .tupleof for static array
Thanks for this solution as well. On Tuesday, 10 August 2021 at 13:10:23 UTC, Paul Backus wrote: Would definitely be nice to have this in the language, though. Do you know more use cases for this?
Re: .tupleof for static array
Thanks! I was considering turning the static array into an AliasSeq directly, but casting it to a struct and doing tupleof on that is pretty smart. On Tuesday, 10 August 2021 at 12:50:55 UTC, jfondren wrote: And I don't see very many static-array-generic functions in Phobos. Indeed, static arrays could use some more love in my opinion.
.tupleof for static array
```D
struct Vec {
float x, y, z;
}
void setPosition(float x, float y, float z) {
}
void main() {
Vec posS = Vec(10, 20, 30);
setPosition(posS.tupleof); // pass
float[3] posA = [10, 20, 30];
setPosition(posA.tupleof); // Error: no property `tupleof`
for type `float[3]`
}
```
Does anyone know a library utility to make expanding a static
array like this work?
Re: Tracy
On Sunday, 8 August 2021 at 01:37:42 UTC, SealabJaster wrote: Could this be fixed? Or is this intentional? Of course it *could*, anyone can go to [the dlang wiki](https://wiki.dlang.org/LDC) and add a page for it. Johan Engelen is still working on [improving the feature](https://github.com/ldc-developers/ldc/pull/3797), maybe he is intentionally waiting for the feature to reach maturity before putting it on the wiki or [his blog](https://johanengelen.github.io/), but I can't say.
