Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Wednesday, 15 May 2024 at 14:23:32 UTC, RazvanN wrote: On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis! We have a bunch of projects that you could work on, however, choosing the right project depends of what you are interested in and your experience with the concepts involved. Generally, we have multiple fronts that work could be done on: the compiler, the runtime library, the standard library, ecosystem tools etc. I suggest you pick one of the categories, get the code, try to fix the issues (you can find our list of issues here: https://issues.dlang.org/ - searching for the keywork "bootcamp" will list issues that are considered entry level, but note that some of those might be more complicated then you would expect at a first glance) and then we can have a hat on projects you can work on. How does that sound? RazvanN just in case I've worked on an issue, how do I communicate with the community/mentors about it? Is there a discord/slack community I can join?
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Wednesday, 15 May 2024 at 14:23:32 UTC, RazvanN wrote: On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis! We have a bunch of projects that you could work on, however, choosing the right project depends of what you are interested in and your experience with the concepts involved. Generally, we have multiple fronts that work could be done on: the compiler, the runtime library, the standard library, ecosystem tools etc. I suggest you pick one of the categories, get the code, try to fix the issues (you can find our list of issues here: https://issues.dlang.org/ - searching for the keywork "bootcamp" will list issues that are considered entry level, but note that some of those might be more complicated then you would expect at a first glance) and then we can have a chat on projects you can work on. How does that sound? RazvanN That sounds great, looking forward to participate.
My interest in contributing to the D language and participation in the Symmetry Autumn of code
Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that.
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: Release D 2.107.0
On Friday, 2 February 2024 at 11:26:11 UTC, Richard (Rikki) Andrew Cattermole wrote: Doesn't look like any of Dennis's work on improving the Unicode tables for Phobos has made it in this release. The master branch for 2.107 was cut off on Jan 1st, and the table improvements came after that. They will be in 2.108 though!
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: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 19:13:38 UTC, Steven Schveighoffer wrote: As I understand the current thinking, that is not what D is intending to do. Additional changes don't require a new edition to be enabled, only breaking changes. I expect editions to mostly subtract code, by turning existing deprecations into errors and enabling preview switches like nosharedaccess, dip1000, fixImmutableConv, systemVariables.
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: D Language Foundation April 2023 Monthly Meeting Summary
On Sunday, 14 May 2023 at 19:38:38 UTC, ryuukk_ wrote: Now you suggest me to depend on WASI by default Unbelievable It's getting hard to maintain composure Then I'll leave it here. There's apparently a big problem with the solutions I provided that I'm supposed to know, but I don't, and that frustrates you. I would try to inquire more, but I'm afraid you will only get more upset, so I won't.
Re: D Language Foundation April 2023 Monthly Meeting Summary
On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote: WASI is not WASM, please don't suggest that as a solution, it's not, this is frustrating to read what you suggest when i bring to you problems I've literally had the same problem as you (missing references to libc symbols when targeting WebAssembly), and solved it by compiling and linking wasi-libc. I can't help you when you reject solutions simply by calling them 'not a solution' and no further details. I'll end up just sticking to C if nobody understand How would you do array copies when using C targeting WebAssembly?
Re: D Language Foundation April 2023 Monthly Meeting Summary
On Sunday, 14 May 2023 at 16:02:00 UTC, ryuukk_ wrote:
I wanted to target WASM, if your hooks call into libC, i can't
target WASM..
Good news, there's implementations of libc for WASM (example:
https://archlinux.org/packages/community/any/wasi-libc/), and
linking them doesn't even increase build time or binary size that
much in my experience. I did this for
[ctod](https://github.com/dkorpel/ctod/tree/master) because I had
to (the tree-sitter library I use depends on it), but I also
incorporated it in my other WASM projects to get a better
`malloc/free` implementation.
You keep tell us that the plan is "pay as you go", well, sir,
that kind of issue goes against your plan, so again, what's the
plan?
The "pay as you go" plan relates to druntime, not libc. Not that
we deliberately depend on libc when it's not needed (don't need
`itoa`, we have `unsignedToTempString`), but certain libc calls
are so standard, common, and optimized, that there's not much
benefit in trying to roll our own implementation for it. I'm
talking about memset, memcpy, memcmp, malloc, free, realloc, off
the top of my head.
Even when there's not a single mention of `memcpy` in druntime,
LDC might still even emit it causing your WASM project to fail to
link. Just check the asm for this code:
```D
struct S { char[1000] x; }
void c()
{
S s = S.init; // emits a `memcpy` (-O0) or `memset` (-O3)
f();
}
void f(S* s);
```
There might be an obscure compiler flag to disable this, but it's
a lot easier to just include an implementation of `memcpy`,
`memset` and `memcmp` yourself.
Then my project no longer compile, thanks a lot!
When you use a custom druntime, you can't expect stability when
you upgrade the compiler but not your druntime. The real issue
here is that there is no proper support for WebAssembly in
upstream druntime.
https://github.com/dlang/dmd/pull/14910
Nobody care anymore.
I fixed that for you: https://github.com/dlang/phobos/pull/8726
Re: exponential errors
On Monday, 8 May 2023 at 05:01:44 UTC, anonymouse wrote: This is a macOS issue. Don't know if it's specific to Ventura but I just loaded up a Debian VM and it runs as expected. Indeed. Apparently Apple changed their floating point parsing function in their C runtime library, causing dmd to fail to parse certain floating pointing numbers in std.math. See issue https://issues.dlang.org/show_bug.cgi?id=23846. It has been fixed, but you'll need to update to 2.104.0 which is currently in beta.
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: Tutorial on LDC's -ftime-trace
On Tuesday, 2 May 2023 at 12:28:32 UTC, Guillaume Piolat wrote: More tips: - `--ftime-trace` was introduced a while back, at least back in LDC 1.27 or perhaps even earlier. I've tested it in LDC 1.30 and works perfectly. So you can probably already use it without upgrading LDC. True, but you don't get CTFE tracking and the timetrace2txt tool with those earlier versions, so I wanted to make sure viewers don't get tripped up by that when following the video.
Re: Tutorial on LDC's -ftime-trace
On Monday, 1 May 2023 at 17:56:21 UTC, Johan wrote: - You forgot about the `--ftime-trace-granularity=` option ;-P - The timetrace can also tell you which parts of your program to separate into separate files + separate compilation. Good suggestions. This video I wanted to focus on setting it up and getting started, but I might do a follow up with more advanced usage.
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: Blog post on figuring out attribute inference failure
On Sunday, 19 February 2023 at 19:40:26 UTC, Steven Schveighoffer wrote: https://www.schveiguy.com/blog/2023/02/spelunking-attribute-inference-in-d/ "Hopefully these improvements will be mimicked for all attributes, and instrumenting code will be a thing of the past!" I'm working on it! https://github.com/dlang/dmd/pull/14911
Re: Hipreme Engine is fully ported to WebAssembly
On Sunday, 5 February 2023 at 18:48:05 UTC, Richard (Rikki) Andrew Cattermole wrote: It never got upstreamed because it was never attempted. I checked, no PR's for druntime. It's on LDC: https://github.com/ldc-developers/ldc/pull/3345
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
}
```
ctod: a tool that translates C code to D
# ctod
**GitHub:** https://github.com/dkorpel/ctod
**Dub:** https://code.dlang.org/packages/ctod
---
In the summer of 2020, before ImportC, I wrote a tool to help me
with my D translations of C libraries:
[glfw-d](https://code.dlang.org/packages/glfw-d) and
[libsoundio-d](https://code.dlang.org/packages/libsoundio-d). I
wanted to publish it at some point but kind of forgot about it,
until [Steven Schveighoffer asked about
it](https://github.com/dkorpel/glfw-d/discussions/18) last week
for his [D translation of
raylib](https://github.com/schveiguy/draylib). That made me
inspired to work on it again, and I finally fixed the Windows
build, so I want to share it now.
It uses
[tree-sitter-c](https://github.com/tree-sitter/tree-sitter-c) to
parse .c or .h files including preprocessor directives, and then
replaces C syntax patterns with roughly equivalent D patterns
wherever it needs and can. Because tree-sitter is very good at
error-recovery, it will always output a best-effort translated .d
file, no matter the content of the .c file.
Example input file main.c:
```C
#include
#define TAU 6.283185307179586476925
int main(void) {
char buf[32];
sprintf(buf, "tau = %f\n", TAU);
Wait, this line is not C syntax 樂
return 0;
}
```
Output main.d:
```D
module main;
@nogc nothrow:
extern(C): __gshared:
public import core.stdc.stdio;
enum TAU = 6.283185307179586476925;
int main() {
char[32] buf;
sprintf(buf.ptr, "tau = %f\n", TAU);
Wait, this_ line is_; not C syntax 樂
return 0;
}
```
The output is supposed to be a good starting point for manual
translation: tedious syntax changes are done for you, but you're
left with the task of translating (non-trivial) macros, fixing
errors because of D's stricter type system, and other misc things
ctod doesn't translate properly yet (see also [issues on
GitHub](https://github.com/dkorpel/ctod/issues) ).
With the rise of ImportC the use cases for this tool decrease,
but in case you still find yourself translating C to D, I hope
this is of use to you!
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: Walter's Edited DConf Talk Video -- Feedback Request
On Wednesday, 7 September 2022 at 12:42:35 UTC, Mike Parker wrote: https://youtu.be/iuP-AWUyjp8 I suggest boosting the audio as much as you can before it starts clipping. It's currently a bit low.
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: Winners of the 1st Jan - 31st March 2022 Bugzilla Cycle
On Monday, 4 April 2022 at 11:11:25 UTC, RazvanN wrote: 1. MoonlightSentinel 830 points 2. ljmf00270 points 3. aG0aep6G 240 points Congratulations!
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: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: One of the problems with going to DIP 1000 by default is what to do about `ref return scope` ambiguity. Walter had finally come up with a fix that was half-implemented. Some of the PRs had been merged, but others were stalled. Those stalled PRs are blocking progress on DIP 1000, and he wants to get those moving. Status update: the `ref return scope` ambiguity is fixed now ([PR 13693](https://github.com/dlang/dmd/pull/13693)), as well as the invalid [pure->scope inferrence](https://github.com/dlang/dmd/pull/12989) and [inout->return inference](https://github.com/dlang/dmd/pull/12689). Currently, most remaining open issues are related to nested functions. Atila resumed work on making dip1000 the default [by printing deprecation messages for scope errors](https://github.com/dlang/dmd/pull/12578).
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 10:08:50 UTC, meta wrote: Are CI/CD builds available somewhere? on GitHub? You can get a nightly build here: https://github.com/dlang/dmd/releases Regular releases are not hosted on GitHub (yet).
Re: Our New Pull-Request and Issue Manager
On Thursday, 24 February 2022 at 20:32:25 UTC, Arjan wrote: Goed bezig! Veel plezier en succes Dennis. Dank jullie wel! Thank you all!
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: D Language Foundation Monthly Meeting, December 2021
On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote: He then talked about a discovery he had made when playing around with the DMD internals which he isn't yet ready to publicize. Is this something good or bad?
