". [1]. Internally this is implemented using
a string appender [2, 3].
However, this string appender is a member of the class, and this is the
source of the bug, because it's shared among all the calls to the
logger. It's usually protected by a mutex, so different threads don't
mess with
On Wednesday, 1 November 2023 at 17:26:42 UTC, Christian Köstlin
wrote:
...
It's really weird: https://run.dlang.io/is/fIBR2n
Interesting because I wrote a similar test as you did. And that
increment (Or lack of) called my attention, If I can I'll try and
take a look at that (std.logger)
n foo");
return "Hello, world.";
}
```
...
Unless you do:
string s;
info(s=foo());
I think this is a bug, or at least very weird behavior.
Matheus.
It's really weird: https://run.dlang.io/is/fIBR2n
...
Unless you do:
string s;
info(s=foo());
I think this is a bug, or at least very weird behavior.
Matheus.
be documented. Should I open a bug
about it?
Hi,
Today I have just found a weird bug in std.logger. Consider:
```d
import std.logger : info;
void main() {
info(foo());
}
auto foo() {
info("In foo");
return "Hello, world.";
}
```
The output is:
```
2023-10-31T20:41:05.274 [info] onlineapp.d:8:foo In
On Thursday, 14 September 2023 at 03:23:48 UTC, An Pham wrote:
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f",
f));
On Wednesday, September 13, 2023 9:23:48 PM MDT An Pham via Digitalmars-d-
learn wrote:
> import std.stdio;
>
> void main()
> {
> float f = 6394763.345f;
>
> import std.format : sformat;
>
> char[80] vBuffer = void;
> writeln("6394763.345 = ",
import std.stdio;
void main()
{
float f = 6394763.345f;
import std.format : sformat;
char[80] vBuffer = void;
writeln("6394763.345 = ", sformat(vBuffer[], "%.4f", f));
}
Output
6394763.345 = 6394763.5000
On 6/30/23 17:42, Cecil Ward wrote:
> https://dlang.org/spec/hash-map.html#testing_membership in the language
> docs, under associative arrays - 13.3 testing membership. Would anyone
> else care to try that example out as that might be quicker?
I tried it by
1) Putting all the code inside a
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
On Friday, 30 June 2023 at 21:25:23 UTC, H. S. Teoh wrote:
On Fri, Jun 30, 2023 at 07:05:23PM +, Cecil Ward via
Digitalmars-d-learn wrote: [...]
It would help if you could post the complete code that
reproduces the problem. Or, if you do not wish to reveal your
code, reduce it to a
https://forum.dlang.org/thread/duetqujuoceancqtj...@forum.dlang.org
Try HashMap see if it is still a problem.
If no, then it's another example of the built in AA problem.
On Fri, Jun 30, 2023 at 07:05:23PM +, Cecil Ward via Digitalmars-d-learn
wrote:
[...]
It would help if you could post the complete code that reproduces the
problem. Or, if you do not wish to reveal your code, reduce it to a
minimal case that still exhibits the same problem, so that we can
On 6/30/23 13:16, Cecil Ward wrote:
On Friday, 30 June 2023 at 19:58:39 UTC, FeepingCreature wrote:
Note that you can do `uint ordinal = Decls.ordinals.get(str, -1);`.
Is the second argument an ‘else’ then, my friend?
Yes, .get and friends appear in this table:
On Friday, 30 June 2023 at 19:58:39 UTC, FeepingCreature wrote:
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
On Friday, 30 June 2023 at 20:12:08 UTC, Ali Çehreli wrote:
On 6/30/23 12:05, Cecil Ward wrote:
> I have code roughly like the following:
>
> dstring str = "name"d;
Aside: One almost never needs dstring.
> uint ordinal = (( str in Decls.ordinals ) !is null) ?
> Decls.ordinals[ str ]
On 6/30/23 12:05, Cecil Ward wrote:
> I have code roughly like the following:
>
> dstring str = "name"d;
Aside: One almost never needs dstring.
> uint ordinal = (( str in Decls.ordinals ) !is null) ?
> Decls.ordinals[ str ] : -1;
>
> struct Decls
> {
> uint[ dstring]
On Friday, 30 June 2023 at 19:05:23 UTC, Cecil Ward wrote:
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
I have code roughly like the following:
dstring str = "name"d;
uint ordinal = (( str in Decls.ordinals ) !is null) ?
Decls.ordinals[ str ] : -1;
struct Decls
{
uint[ dstring] ordinals;
}
//and
Decls.ordinals[ str ] = ordinal_counter++;
The problem is that it always
UPDATE: life is too short to debug dlang built-in AA to right,
let's just use HashMap from emsi_containers
https://github.com/mw66/grpc-d/blob/master/source/grpc/server/package.d#L25
```
HashMap!(string, ServiceHandlerInterface) services;
```
After this change, the problem goes away.
I think
Hi,
I recently found and started playing with the grpc-d-core[1]
package, and my program structure looks like this:
https://github.com/mw66/grpc-demo/blob/master/source/main.d
If I run L64 alone (without L66 ~ 79 grpc-d part):
```
64: auto t = new Thread({fun();}).start();
```
it works fine.
On Thursday, 16 March 2023 at 04:31:11 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
[...]
Correction.
With or without comments, mostly it doesn't compile,
occasionally it does!
I have no idea.
On Thursday, 16 March 2023 at 04:04:51 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct
On Thursday, 16 March 2023 at 03:44:19 UTC, Elfstone wrote:
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
[...]
Oops, the above code compiles, because I added comments!!!
Now this really doesn't compile:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S,
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3, 1) == Matrix!(S, 3, 1), S)); //
Error: declaration `S` is
On Thursday, 16 March 2023 at 03:40:04 UTC, Elfstone wrote:
```D
struct Matrix(S, size_t M, size_t N)
{
}
alias Vec3(S) = Matrix!(S, 3, 1);
void main()
{
import std.stdio;
writeln(is(Vec3!float == Matrix!(S, 3, 1), S)); // `alias`
`S` is defined here
writeln(is(Matrix!(float, 3,
On Friday, 3 March 2023 at 01:37:42 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 03/03/2023 2:33 PM, ryuukk_ wrote:
So it is a DMD bug?
Yes and thanks to you I can now say that we can absolutely get
rid of DllMain requirement for DLLs!
glad the outcome is positive, and i apologies
be
summarized as "that's what ends up happening due to the details
of the implementation".
4. is this a bug in DMD or my code is wrong?
I would say the code is wrong in principle, though as you've
noted it can still work in some specific circumstances.
5. if it's wrong, then why does
I added a note here: https://issues.dlang.org/show_bug.cgi?id=20737
On 03/03/2023 2:33 PM, ryuukk_ wrote:
So it is a DMD bug?
Yes and thanks to you I can now say that we can absolutely get rid of
DllMain requirement for DLLs!
();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a value,
but TLS itself is working.
So it is a DMD bug?
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
```d
Stuff[] stuffs;
```
The problem here is dmd isn't initializing TLS with a
. why it doesn't work when DMD is invoked once for build/link
4. is this a bug in DMD or my code is wrong?
5. if it's wrong, then why does it compile/no error?
```sh
#!/usr/bin/env bash
set -e
build_dmd() {
echo "build dmd"
dmd \
-debug -g \
-m64 -vcolumns -
On Friday, 3 March 2023 at 01:07:07 UTC, ryuukk_ wrote:
I couldn't figure out dustmite, so i started from 0 and managed
to hit something:
https://github.com/ryuukk/dmd_bug
``Assertion failed: array index out of bounds, file game\app.d,
line 5``
Wich indicates probably TLS problem?
I couldn't figure out dustmite, so i started from 0 and managed
to hit something:
https://github.com/ryuukk/dmd_bug
``Assertion failed: array index out of bounds, file game\app.d,
line 5``
Wich indicates probably TLS problem?
This now reminds me of:
On 03/03/2023 10:38 AM, ryuukk_ wrote:
On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew
Cattermole wrote:
There isn't anything we can do without source.
But here is what I would do in this situation:
1. Look at the assembly at the point of debug break, from here it
should
On 3/2/23 15:34, ryuukk_ wrote:
> the problem is not that it can run in the background, the problem is
> figuring out
>
> 1. how to install
> 2. how to setup
> 3. how to run
I haven't used it myself but dustmite seems to be integrated into dub.
'dub dustmite <...>'
Ali
On 03/03/2023 12:34 PM, ryuukk_ wrote:
1. how to install
Already is.
Comes with dmd and ldc.
You can also just do ``$ dub run digger -- args``.
2. how to setup > 3. how to run
It is a bit of a pain but the basics is you need some sort of
compilation command, list of sources and a test
e to a minimal example
that still exhibits the same problem, good for bug reports that
are easily reproducible. Also useful if you don't want to
publicly share the code for whatever reason, but still want to
provide enough information so that the dmd devs can find the
problem and fix it.
[...]
Th
ve something we can work with.
> >
> > [...] 2. do you have a link for a guide how to setup "dustmite"?
https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/
Dustmite automatically reduces your code to a minimal example that still
exhibits the same
On Thursday, 2 March 2023 at 21:38:23 UTC, ryuukk_ wrote:
On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki)
Andrew Cattermole wrote:
There isn't anything we can do without source.
But here is what I would do in this situation:
1. Look at the assembly at the point of debug break, from
On Thursday, 2 March 2023 at 21:21:14 UTC, Richard (Rikki) Andrew
Cattermole wrote:
There isn't anything we can do without source.
But here is what I would do in this situation:
1. Look at the assembly at the point of debug break, from here
it should give you hints as to why its trying to
There isn't anything we can do without source.
But here is what I would do in this situation:
1. Look at the assembly at the point of debug break, from here it should
give you hints as to why its trying to write to dawn.assets.Resource
init array.
2. Dustmite, so we have something we can
It crashes with a weird message, address doesn't match the
mangled name:
``C:\dev\kdom\projects\dawn\gl\glad\loader.d``
inside: ``module dawn.gl.glad.loader;``
Hello,
I encountered a weird issue, my program segfault when i feed DMD
with my files and static libs
It doesn't when i compile with LDC
If i split the compile/link in 2 different steps, then all works
correctly
DMD (1step: ⛔):
On Saturday, 7 January 2023 at 02:31:14 UTC, Ali Çehreli wrote:
On 1/6/23 17:50, Arredondo wrote:
> Would anyone volunteer to file a bug report?
Me! Me! :)
https://issues.dlang.org/show_bug.cgi?id=23604
Ali
Thanks a lot :D
Arredondo.
On 1/6/23 17:50, Arredondo wrote:
> Would anyone volunteer to file a bug report?
Me! Me! :)
https://issues.dlang.org/show_bug.cgi?id=23604
Ali
On Saturday, 7 January 2023 at 00:52:20 UTC, Ali Çehreli wrote:
Although that difference is a bug, iota does have a special
floating point implementation to prevent the accumulation of
floating point errors.
Thank you for this clarification Ali. I appreciate the fact
On 1/6/23 15:23, Arredondo wrote:
> then you get an exception (incorrect startup parameters).
Although that difference is a bug, iota does have a special floating
point implementation to prevent the accumulation of floating point
errors. I mention it as item 4 here:
ht
Consider:
```
import std.range.iota;
auto r = iota(5, 0);
```
`r` is an empty range, as it should be. But if you call:
```
auto r = iota(5.0, 0);
```
then you get an exception (incorrect startup parameters).
This was unexpected, and a pain to debug. What is the rationale
behind iota having
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto
On Thursday, 15 December 2022 at 20:12:12 UTC, Ali Çehreli wrote:
I think this is a bug because the documentation clearly talks
about destroying the object:
OK: https://github.com/dlang/phobos/pull/8651
> do we need to do some kind of deprecation?
The behavior is so different f
On 12/15/22 11:31, Nick Treleaven wrote:
> On Wednesday, 14 December 2022 at 17:41:07 UTC, Ali Çehreli wrote:
>> I've never used Unique but I think it has a bug (or a design issue?):
>> Its destructor is the following:
>>
>> ~this()
>>
On Thursday, 15 December 2022 at 20:02:38 UTC, Nick Treleaven
wrote:
auto f() return @trusted => p ? p : v.ptr;
Whoops, that can't be @trusted unless I `assert(p)`.
On Saturday, 19 November 2022 at 15:24:33 UTC, Dukc wrote:
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
OK, so how do I make `lf` implicitly scope?
Have the `int*` inside it to point to a local, or assign
another `scope int*` to it.
Thanks, this works:
```d
@safe:
On Wednesday, 14 December 2022 at 17:41:07 UTC, Ali Çehreli wrote:
I've never used Unique but I think it has a bug (or a design
issue?): Its destructor is the following:
~this()
{
if (_p !is null)
{
destroy(_p);
_p = null
On Friday, 25 November 2022 at 15:03:57 UTC, ShadoLight wrote:
I don't grok how `lf` can survive the local scope. Or am I
missing something?
Perhaps because the local scope is not pushed as a separate
(anonymous) function on the stack... if true then, yes, then
`lf` will indeed have the same
On Friday, 25 November 2022 at 17:45:57 UTC, Paul Backus wrote:
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus
wrote:
Since, in your example, `lf` has global lifetime, the
compiler deduces that `lf.fp` also has global
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus
wrote:
Since, in your example, `lf` has global lifetime, the compiler
deduces that `lf.fp` also has global lifetime, and therefore
there is nothing wrong with assigning it
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus wrote:
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
```D
@safe:
int* fp(return scope int* p) { return p; }
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
OK, so how do I make `lf` implicitly scope?
By explicit/implicit I just meant this:
scope explicit = new int;
int x;
auto implicit =
That's probably not helping with whatever you want to accomplish.
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
@safe:
int* fp(return scope int* p) { return p; }
void main()
{
int* p;
{
auto lf = new int;
p =
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto
On 19.11.22 15:07, Nick Treleaven wrote:
Hi,
The following seems like a bug to me (reduced code, FILE* changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new
Hi,
The following seems like a bug to me (reduced code, FILE* changed
to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
p = lf.fp;
}
assert(p != n
On Tuesday, 1 November 2022 at 19:49:47 UTC, mw wrote:
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven
Schveighoffer wrote:
[...]
Maybe the hunt library author doesn't know. (My code does not
directly use this library, it got pulled in by some other
decencies.)
[...]
Please, if
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer
wrote:
Oh yeah, isDaemon detaches the thread from the GC. Don't do
that unless you know what you are doing.
As discussed on discord, this isn't actually true. All it does is
prevent the thread from being joined before exiting
= true; // not sure if this is
related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like
someone run into this (cleanup) issue already, but unable to
fix it.
Anyway I logged an issue there:
https://github.com/huntlabs/hunt/issues/96
Oh yeah, isDaemo
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer
wrote:
Oh yeah, isDaemon detaches the thread from the GC. Don't do
that unless you know what you are doing.
As discussed on discord, this isn't true actually. All it does is
prevent the thread from being joined before exiting
/source/hunt/util/DateTime.d#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone run
into this (cleanup) issue already, but una
#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone
run into this (cleanup) issue already, but unable to fix it.
Anyway I logge
On Tue, Nov 01, 2022 at 10:37:57AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 11/1/22 10:27, H. S. Teoh wrote:
>
> > Maybe try running Digger to reduce the code for you?
>
> Did you mean dustmite, which is accessible as 'dub dustmite
> ' but I haven't used it.
Oh yes, sorry, I
On 11/1/22 10:27, H. S. Teoh wrote:
> Maybe try running Digger to reduce the code for you?
Did you mean dustmite, which is accessible as 'dub dustmite
' but I haven't used it.
My guess for the segmentation fault is that the OP is executing
destructor code that assumes some members are
On Tue, Nov 01, 2022 at 05:19:56PM +, mw via Digitalmars-d-learn wrote:
> My program received signal SIGSEGV, Segmentation fault.
>
> Its simplified structure looks like this:
>
> ```
> void foo() {
> ...
> writeln("done"); // saw this got printed!
> }
>
> int main() {
> foo();
>
ead (maybe due to foreach parallel) cleanup bug
somewhere, which is unrelated to my own code. This kind of bug is
hard to re-produce, not sure if I should file an issue.
I'm using: LDC - the LLVM D compiler (1.30.0) on x86_64.
Under gdb, here is the threads info (for the record):
Thre
On Saturday, 24 September 2022 at 06:13:55 UTC, test123 wrote:
If so please report it for me to bugs platform. I can not
register one.
```d
package {
version(TEST) {
static:
} else {
__gshared:
}
uint test = 0;
}
```
ldmd2 -betterC -vtls -c ./test.d
On Saturday, 24 September 2022 at 06:13:55 UTC, test123 wrote:
If so please report it for me to bugs platform.
This isn't a bug, the effect of keyword: things stop at the
matching }.
(static if and version don't introduce a namespace scope, but
they still follow this rule for the { colon
On Saturday, 24 September 2022 at 07:11:12 UTC, rikki cattermole
wrote:
```d
version(all) {
__gshared:
uint test2;
}
uint test;
```
Output with -vtls:
```
Up to 2.079.1: Success with output: onlineapp.d(9): test
is thread local
Since 2.080.1: Success with output:
```d
version(all) {
__gshared:
uint test2;
}
uint test;
```
Output with -vtls:
```
Up to 2.079.1: Success with output: onlineapp.d(9): test is thread
local
Since 2.080.1: Success with output: onlineapp.d(9): `test` is
thread local
```
Looks fine to me.
If so please report it for me to bugs platform. I can not
register one.
```d
package {
version(TEST) {
static:
} else {
__gshared:
}
uint test = 0;
}
```
ldmd2 -betterC -vtls -c ./test.d
./test.d(7): `test` is thread local
Provide two functions and let the caller choose
```
void fun(ref Variant v) nothrow
{
}
void fun2(Variant v)
{
fun(v);
}
```
On Friday, 16 September 2022 at 22:43:43 UTC, frame wrote:
```d
import std.variant;
// error: destructor `std.variant.VariantN!32LU.VariantN.~this`
is not `nothrow`
void fun(Variant v) nothrow
{
}
void main()
{
fun(Variant());
}
```
A reference, pointer or slice works. I could do
On Sat, Sep 17, 2022 at 12:19:16AM +, frame via Digitalmars-d-learn wrote:
> On Friday, 16 September 2022 at 23:06:35 UTC, H. S. Teoh wrote:
>
> > Basically, if you pass something to .fun by value, then that value
> > must be destroyed by .fun once it's ready to return. So if the
> > value
On Friday, 16 September 2022 at 23:06:35 UTC, H. S. Teoh wrote:
Basically, if you pass something to .fun by value, then that
value must be destroyed by .fun once it's ready to return. So
if the value has a dtor, the dtor must be called upon exiting
from .fun. Since Variant has a throwing
On Fri, Sep 16, 2022 at 10:43:43PM +, frame via Digitalmars-d-learn wrote:
> ```d
> import std.variant;
>
> // error: destructor `std.variant.VariantN!32LU.VariantN.~this` is not
> `nothrow`
> void fun(Variant v) nothrow
> {
>
> }
>
> void main()
> {
>fun(Variant());
> }
> ```
>
> A
```d
import std.variant;
// error: destructor `std.variant.VariantN!32LU.VariantN.~this`
is not `nothrow`
void fun(Variant v) nothrow
{
}
void main()
{
fun(Variant());
}
```
A reference, pointer or slice works. I could do something on the
caller site but the signature of `fun()` should
On Thursday, 15 September 2022 at 11:33:43 UTC, Dennis wrote:
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote:
I hope we have github bugs.
It's being worked on.
glad to know we are move into github.
Please help me create a bug report if who has free time and
bugs account
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
On Wednesday, 14 September 2022 at 14:41:38 UTC, Steven
Schveighoffer wrote:
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e = & d;
```
the `e`
from
`const(validate_KnownRegex_enum_init_type)*` to
`const(upb_MiniTable_Enum)*` is not supported in CTFE
```
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e =
```
./test.d(4): Error: expression `(3u, 4u).a` is not a constant
I need this to work around C struct array member like this:
```c
struct c {
uint32_t a, b;
uint32_t[] arr;
}
```
If I can
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B
b) pure nothrow @nogc @safe => a])` does not match template
declaration `opBi(A, A function(A, A)[string] f0)`
```
Is this a bug or am I do
On Friday, 22 July 2022 at 12:56:44 UTC, Adam D Ruppe wrote:
```
mixin template opBi(
alias f0
) {
static foreach (k, f; f0) { typeof(this) opBinary(string op:
k)(typeof(this) r) { return f(this, r); } }
}
```
Thanks, this seems to do the trick.
Will not let me override operators on both struct A and B.
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B b) pure
nothrow @nogc @safe => a])` does not match template declaration `opBi(A,
A function(A, A)[string] f0)`
```
Is this a bug or am I doin
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
Is this a bug or am I doing something wrong?
I think this is a bug. The compiler must not take well to this
pattern, maybe the assoc array template argument, but idk. It
looks like the first type used gets cached and reused even
1 - 100 of 1912 matches
Mail list logo
