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 'vo
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
Decls.ordinals[
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 minima
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 see
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:
https://dlang.org/spec/ha
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] ordina
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
Decls.ordinals[
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 about
On Friday, 3 March 2023 at 01:21:52 UTC, ryuukk_ wrote:
I have some questions:
1. why does it work with LDC?
2. why does it work with DMD when build/link in 2 step?
3. why it doesn't work when DMD is invoked once for build/link
I think these are probably coincidences and the answer can be
sum
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!
On Friday, 3 March 2023 at 01:24:42 UTC, Richard (Rikki) Andrew
Cattermole wrote:
This works:
```d
extern(C) void main()
{
Stuff[5] temp = [
Stuff(),
Stuff(),
Stuff(),
Stuff(),
Stuff(),
];
stuffs = temp[];
stuffs[0].do_something();
}
```
`
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 valu
On Friday, 3 March 2023 at 01:11:06 UTC, Vladimir Panteleev wrote:
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
g
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?
Yeah...
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:
https://issues.dlang.org/show_bug.cgi?id
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 giv
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 to
On Thursday, 2 March 2023 at 22:24:11 UTC, H. S. Teoh wrote:
On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via
Digitalmars-d-learn wrote:
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:
[..
On Thu, Mar 02, 2023 at 09:55:55PM +, ryuukk_ via Digitalmars-d-learn wrote:
> 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:
[...]
> > > 2. Dustmite, so we have something we can work with.
>
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 writ
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 work
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;``
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 that
there is a specializ
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:
https://www.youtube.com
On Wednesday, 15 June 2022 at 16:53:13 UTC, mw wrote:
Create a simple test case, file bug at:
https://issues.dlang.org/
I tried. No luck.
Create a simple test case, file bug at:
https://issues.dlang.org/
On Wednesday, 15 June 2022 at 09:24:35 UTC, Dukc wrote:
Now when I think of it, perhaps the fact that private
`printHelp` has the same name as the public `printHelp` is
somehow confusing dmd. If you try to rename the private
`printHelp` and it's call in the public one to something else,
you mi
On Wednesday, 15 June 2022 at 09:21:28 UTC, user1234 wrote:
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-
[Line (2)
produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=tru
On Wednesday, 15 June 2022 at 07:38:36 UTC, JG wrote:
I tried to reproduce it but wasn't able (I guess it is some
interplay with the rest of your code):
I tried this first but got the same result as you. I think my
small library overheats DMD's template engine.
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote:
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both of the
templat
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-
[Line (2)
produces](https://github.com/andrey-zherikov/argparse/runs/6880350900?check_suite_focus=true#step:5:12) `undefined reference to '_D3std7sumtype__T7SumTy
On Tuesday, 14 June 2022 at 23:56:58 UTC, Andrey Zherikov wrote:
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both of the
templat
On Tuesday, 14 June 2022 at 19:49:39 UTC, Steven Schveighoffer
wrote:
On 6/14/22 3:35 PM, JG wrote:
Hi,
Is this a bug?
```d
import std;
template test(alias f) {
auto test(I)(I i) { return f(i); }
}
void main()
{
alias t = test!(x=>x+1);
1.t.writeln; //<--Doesn't compile
1
On Tuesday, 14 June 2022 at 21:44:48 UTC, Dukc wrote:
No idea. The functions seems indeed to be exactly the same, so
I assume this is a DMD bug. It cannot be a bug in
`std.sumtype`, since that would trigger in both of the
templates.
This definitely triggers some bug in DMD because this `priva
On Tuesday, 14 June 2022 at 13:39:12 UTC, Andrey Zherikov wrote:
I have [pretty simple code in my
library](https://github.com/andrey-zherikov/argparse/blob/bug/source/argparse/help.d#L27-L47):
```d
alias CC = SumType!(AA,BB);
struct AA {}
struct BB
{
CC[] c;
}
private void ppp(T, Output)(au
On 6/14/22 3:35 PM, JG wrote:
Hi,
Is this a bug?
```d
import std;
template test(alias f) {
auto test(I)(I i) { return f(i); }
}
void main()
{
alias t = test!(x=>x+1);
1.t.writeln; //<--Doesn't compile
1.test!(x=>x+1).writeln;
t(1).writeln;
}
```
Not a bug. Local sym
On Wednesday, 2 September 2020 at 20:55:34 UTC, Andrey Zherikov
wrote:
I think the issue is here:
https://github.com/dlang/dmd/blob/master/src/dmd/root/filename.d#L736-L748
Yes, issue is there. This change (removal of "c == '\\' || ")
fixes it:
diff --git a/src/dmd/root/filename.d b/src/dmd/
On Wednesday, 2 September 2020 at 19:13:47 UTC, Adam D. Ruppe
wrote:
On Wednesday, 2 September 2020 at 18:40:55 UTC, Andrey Zherikov
wrote:
If I provide -Jfoo to dmd, doesn't it mean my consent to use
the contents of directory foo?
Yeah, but dmd has been inconsistent on platforms about if it
On 9/2/20 4:48 PM, Andrey Zherikov wrote:
On Wednesday, 2 September 2020 at 20:23:15 UTC, Steven Schveighoffer wrote:
What I'm wondering is if it needs to be ./file instead of .\file. Can
you hard code that and see if it works?
This actually works:
pragma(msg, import("file"));
pragma
On Wednesday, 2 September 2020 at 20:23:15 UTC, Steven
Schveighoffer wrote:
What I'm wondering is if it needs to be ./file instead of
.\file. Can you hard code that and see if it works?
This actually works:
pragma(msg, import("file"));
pragma(msg, buildPath(".", "file"));
pragma(msg
On 9/2/20 1:47 PM, Adam D. Ruppe wrote:
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec for the
compiler to reject any path comp
On Wednesday, 2 September 2020 at 18:40:55 UTC, Andrey Zherikov
wrote:
If I provide -Jfoo to dmd, doesn't it mean my consent to use
the contents of directory foo?
Yeah, but dmd has been inconsistent on platforms about if it
allows subdirectories. Right now I think it just strips all
slashes o
On Wednesday, 2 September 2020 at 17:47:47 UTC, Adam D. Ruppe
wrote:
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov
wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec for
the com
On Wednesday, 2 September 2020 at 17:39:04 UTC, Andrey Zherikov
wrote:
Is this a bug in dmd?
I think it is an old bug filed (I can't find it though) about
inconsistent platform behavior but it is allowed by spec for the
compiler to reject any path components.
import("") is supposed to just
Adding some verbosity:
pragma(msg, import("file"));
pragma(msg, buildPath(".", "file"));
pragma(msg, import(buildPath(".", "file")));
Result on Ubuntu:
===
hello
./file
hello
===
Result on Windows:
===
hello
.\file
parser.d(47): Error: file ".\\file" cannot be found o
On Monday, 11 May 2020 at 13:06:59 UTC, Steven Schveighoffer
wrote:
Clearly something isn't connecting properly, it's almost like
it's resolving to the function itself instead of calling it.
Since the imported front is also a local symbol the compiler
probably thinks it is overloaded and not h
On Monday, 11 May 2020 at 13:12:37 UTC, Simen Kjærås wrote:
Filed here: https://issues.dlang.org/show_bug.cgi?id=20821
Thanks.
On Monday, 11 May 2020 at 12:44:45 UTC, Jack Applegame wrote:
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote:
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in
local scope so ufcs doesn't apply.
But in this cas
On 5/11/20 8:44 AM, Jack Applegame wrote:
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote:
UFCS is only defined to work with global scope functions. A restricted
import (module : symbol, symbols) puts things in local scope so ufcs
doesn't apply.
But in this case the error should b
On Monday, 11 May 2020 at 12:30:22 UTC, Adam D. Ruppe wrote:
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in
local scope so ufcs doesn't apply.
But in this case the error should be displayed for lines 4 and 5,
not 11.
Li
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote:
If you move the import to the global scope
UFCS is only defined to work with global scope functions. A
restricted import (module : symbol, symbols) puts things in local
scope so ufcs doesn't apply.
(interestingly an unrestricted
And the first example still doesn't compile:
```
struct Range(R) {
import std.array : empty, front, popFront;
R range;
bool empty() const { return range.empty; }
auto front() const { return range.front; }
void popFront() { range.popFront(); }
}
void main() {
auto rng
On Monday, 11 May 2020 at 12:20:06 UTC, Jack Applegame wrote:
assert(rng.front == 1);
Damn! I made a typo. It must be:
assert(rng.front == '1')
So the second example works fine.
On Tuesday, 5 May 2020 at 05:37:08 UTC, Simen Kjærås wrote:
On Tuesday, 5 May 2020 at 04:02:06 UTC, RazvanN wrote:
[...]
Surely the above code, which silently discards the exception,
does not print "hello"?
Regardless, I ran your code with writeln inside the catch(),
and without the try-ca
On Tuesday, 5 May 2020 at 04:02:06 UTC, RazvanN wrote:
truct K
{
~this() nothrow {}
}
void main()
{
static class C
{
this(K, int) {}
}
static int foo(bool flag)
{
if (flag)
throw new Exception("hello");
return 1;
}
try
{
On Wednesday, 22 April 2020 at 18:35:49 UTC, CraigDillabaugh
wrote:
On Wednesday, 22 April 2020 at 18:23:48 UTC, Anonymouse wrote:
On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh
wrote:
clip
File an issue if you have the time, maybe it will get
attention. Unreported bugs can on
On Wednesday, 22 April 2020 at 18:23:48 UTC, Anonymouse wrote:
On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh
wrote:
The crash is caused because the 'income' field with value 0.0
is
output as 0 (rather than 0.0) and when it is read this is
interpreted
as an integer.
Shouldn't t
On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh
wrote:
The crash is caused because the 'income' field with value 0.0 is
output as 0 (rather than 0.0) and when it is read this is
interpreted
as an integer.
Shouldn't this work?
Yes, it's just buggy.
Giving it a value of an even
On Saturday, 14 December 2019 at 10:32:10 UTC, berni44 wrote:
On Saturday, 14 December 2019 at 09:33:13 UTC, Tobias Pankrath
wrote:
See: https://dlang.org/spec/lex.html#integerliteral
What I am aiming at: Is the spec wrong or am I
misunderstanding it and did this change recently?
You are rig
On Saturday, 14 December 2019 at 09:33:13 UTC, Tobias Pankrath
wrote:
See: https://dlang.org/spec/lex.html#integerliteral
What I am aiming at: Is the spec wrong or am I misunderstanding
it and did this change recently?
You are right. The implementation does not do what the specs tell
here.
I
On Saturday, 14 December 2019 at 07:44:37 UTC, berni44 wrote:
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else
the compiler treats it as an int:
On Saturday, 14 December 2019 at 07:09:30 UTC, Tobias Pankrath
wrote:
void main()
{
auto x = 9223372036854775808; // long.max + 1
}
You need to tell, that this is an unsigned long literal, else the
compiler treats it as an int:
void main()
{
auto x = 9223372036854775808UL; // long.ma
On Wednesday, 30 October 2019 at 20:22:25 UTC, Q. Schroll wrote:
struct Example
{
private void helper(int i, this X)() { }
void funcTempl(T, this X)(T value)
{
this.helper!0();
// ^ Why do I need this?
}
}
void main()
{
auto ex = Example();
ex.funcTempl(1
On Sunday, 21 April 2019 at 16:20:51 UTC, WebFreak001 wrote:
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing
some dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and som
On 4/12/19 5:43 AM, Jacob Carlborg wrote:
The problem is that "__traits(getAttributes, T)" in it self is not valid
code. It needs to be part of larger expression or statement.
It does work, as long as it's not an alias passed into a template:
void main()
{
@(3) int a;
static assert(__tr
On Friday, 12 April 2019 at 09:43:01 UTC, Jacob Carlborg wrote:
On 2019-04-11 20:13, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes
~=
There seem
On 2019-04-11 20:13, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code would fail with the
sta
On 4/11/19 6:45 PM, Alex wrote:
On Thursday, 11 April 2019 at 19:42:05 UTC, Steven Schveighoffer wrote:
On 4/11/19 2:13 PM, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttr
On Friday, 12 April 2019 at 00:02:36 UTC, Seb wrote:
On Thursday, 11 April 2019 at 23:55:18 UTC, Alex wrote:
to judge people objectively. This isn't a nursery school and
we are not 3 year olds...
Exactly. So start behaving like a grown-up and professional.
When you ask someone for help on th
On Thursday, 11 April 2019 at 23:55:18 UTC, Alex wrote:
to judge people objectively. This isn't a nursery school and we
are not 3 year olds...
Exactly. So start behaving like a grown-up and professional.
When you ask someone for help on the street, do you curse at him
too?
On Thursday, 11 April 2019 at 23:04:46 UTC, Mike Parker wrote:
On Thursday, 11 April 2019 at 22:41:32 UTC, Alex wrote:
Seriously? Do you think you have ESP? Your code isn't even
close to was talking about ;/
Here is is updated that shows the error. You seem to fail to
understand that it is
On Thursday, 11 April 2019 at 22:41:32 UTC, Alex wrote:
Seriously? Do you think you have ESP? Your code isn't even
close to was talking about ;/
Here is is updated that shows the error. You seem to fail to
understand that it is impossible for it to be my code.
If you continue to attack pe
On Thursday, 11 April 2019 at 19:42:05 UTC, Steven Schveighoffer
wrote:
On 4/11/19 2:13 PM, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes
~=
The
On Thursday, 11 April 2019 at 20:49:45 UTC, bauss wrote:
On Thursday, 11 April 2019 at 18:13:48 UTC, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
On Thursday, 11 April 2019 at 18:13:48 UTC, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code wo
On 4/11/19 2:13 PM, Alex wrote:
The following code works when I comment out the static if
//static if (__traits(compiles, __traits(getAttributes, T)))
static foreach(a; __traits(getAttributes, T)) Attributes ~=
There seems to be absolutely no reason why this code would fail with the
stat
On Thursday, 14 March 2019 at 19:46:30 UTC, spir wrote:
But the doc (the language ref for the matter) should definitely
say what you just explained above, shouldn't they?
Well arguably, the spec should detail the language semantics
formally and not just be a description of the reference
imple
On 14/03/2019 15:52, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Mar 14, 2019 at 03:22:52PM +0100, spir via Digitalmars-d-learn wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
==> Error: non-con
On Thursday, 14 March 2019 at 14:47:18 UTC, Adam D. Ruppe wrote:
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
Well, bug in implementation. That is *supposed* to work, but
the compiler never implemented it.
The docs reall
On Thu, Mar 14, 2019 at 03:22:52PM +0100, spir via Digitalmars-d-learn wrote:
> https://dlang.org/spec/hash-map.html#static_initialization:
>
> immutable long[string] aa = [
> "foo": 5,
> "bar": 10,
> "baz": 2000
> ];
>
> ==> Error: non-constant expression `["foo":5L, "bar":10L, "baz":2000L
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
Well, bug in implementation. That is *supposed* to work, but the
compiler never implemented it.
The docs really should point out this fact explicitly, though.
On Thursday, 14 March 2019 at 14:22:52 UTC, spir wrote:
https://dlang.org/spec/hash-map.html#static_initialization:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
If I'm right, you can't use this syntax with global array. Insted
this works:
void main()
{
immutable
On 1/8/19 3:12 PM, SrMordred wrote:
size_t[2] a;
size_t[2] b;
auto x = a[] & b[]; //array operation without destination memory
not allowed
size_t[2] y = a[] & b[]; // fine
Honestly, I wouldn't have expected either to work. My understanding was
that array operations require slicing on
On Tuesday, 18 December 2018 at 20:33:43 UTC, Rainer Schuetze
wrote:
On 14/12/2018 02:56, Steven Schveighoffer wrote:
On 12/13/18 7:16 PM, Michelle Long wrote:
byte x = 0xF;
ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even
with a ulong.
It doesn't work as in
On 14/12/2018 02:56, Steven Schveighoffer wrote:
> On 12/13/18 7:16 PM, Michelle Long wrote:
>> byte x = 0xF;
>> ulong y = x >> 60;
>
> Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
It doesn't work as intuitive as you'd expect:
void main()
{
int x = 256;
On Fri, 14 Dec 2018 00:16:51 +, Michelle Long wrote:
> byte x = 0xF;
> ulong y = x >> 60;
"Error: shift by 60 is outside the range 0..31"
This is the result of integer promotion rules. Change the 30 to a 60 and
it works, and the result is, as you would expect, 0.
> I thought D required brea
On Friday, 14 December 2018 at 02:17:20 UTC, Jonathan M Davis
wrote:
On Thursday, December 13, 2018 6:56:33 PM MST Steven
Schveighoffer via Digitalmars-d-learn wrote:
On 12/13/18 7:16 PM, Michelle Long wrote:
> I've noticed the compiler is not throwing up errors and
> warnings like it used to:
On Thursday, December 13, 2018 6:56:33 PM MST Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 12/13/18 7:16 PM, Michelle Long wrote:
> > I've noticed the compiler is not throwing up errors and warnings like it
> > used to:
> >
> > I thought D required breaks for cases? Seems it doesn't an
On 12/13/18 7:16 PM, Michelle Long wrote:
byte x = 0xF;
ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
Does not compute the proper value.
It seems that the shift amount is wrapped. My code is more complex. The
code above does give an error. I a
I do not understand you?
What is wrong? It works ok.
https://run.dlang.io/is/ZFf0FQ
What do you mean by D required breaks for cases?
On Fri, Dec 14, 2018 at 1:20 AM Michelle Long via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> byte x = 0xF;
> ulong y = x >> 60;
>
> Does not
On Sunday, September 9, 2018 8:30:12 AM MDT Saurabh Das via Digitalmars-d-
learn wrote:
> Thank you for explaining all this.
>
> It is frustrating because the behaviour is very counterintuitive.
>
> I will use a workaround for now.
Ranges are fantastic, and the basic concept is solid, but a number
Thank you for explaining all this.
It is frustrating because the behaviour is very counterintuitive.
I will use a workaround for now.
Saurabh
1 - 100 of 419 matches
Mail list logo
