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]`
Also: I don't understand the error message:
* What is non-constant in the *expression*?
*
port off_t not found
I cannot explain this error, because off_t is defined in both
cases of the static if.
Even if I change it to:
static if ( true )
alias long off_t;
I get the same error. Is this a compiler bug?
Kind regards
André
On 02/19/2019 03:21 PM, SrMordred wrote:
> On Tuesday, 19 February 2019 at 23:03:37 UTC, Paul Backus wrote:
>> Inside a templated struct, the name of the template, by itself,
>> actually refers to the current instantiation. So when you write `Test`
>> in your __traits(isSame) test, the compiler
On Tuesday, 19 February 2019 at 23:03:37 UTC, Paul Backus wrote:
On Tuesday, 19 February 2019 at 22:43:25 UTC, SrMordred wrote:
import std.traits;
import std.stdio;
struct Test(T)
{
this(T)( auto ref T value )
{
writeln( TemplateOf!(typeof(value)).stringof);
On Tuesday, 19 February 2019 at 22:43:25 UTC, SrMordred wrote:
import std.traits;
import std.stdio;
struct Test(T)
{
this(T)( auto ref T value )
{
writeln( TemplateOf!(typeof(value)).stringof);
writeln( __traits(isSame, TemplateOf!(typeof(value)), Test)
);
import std.traits;
import std.stdio;
struct Test(T)
{
this(T)( auto ref T value )
{
writeln( TemplateOf!(typeof(value)).stringof);
writeln( __traits(isSame, TemplateOf!(typeof(value)), Test) );
}
}
void main(){
auto value =
t to do a check for "x is null" hides the bug. I tried
> assert(), also tried if (x is null) throw new Exception(...)
Aha! That's an important insight. It's almost certain that it's caused
by a backend bug now. So testing the value perturbs the codegen code
path enough to mask the bug /
method hides the bug. Likewise,
replacing writeln with assert makes it work properly too.
Pity we couldn't get rid of std.stdio. It's a pretty big piece
of code, and there are plenty of places where it may go wrong
inside, even though we generally expect that the bug lies
elsewhere. Oh well
On Fri, Feb 08, 2019 at 10:45:39PM +, JN via Digitalmars-d-learn wrote:
[...]
> Anyway, I reduced the code further manually. It's very hard to reduce
> it any further. For example, removing the assignments in
> fromEulerAngles static method hides the bug. Likewise, replacing
for compiler devs
to analyze -- and perhaps look at the generated assembly to see
what went wrong. If you have the time (and patience) to do
that, it would greatly increase the chances of this being fixed
in a timely way, since it would narrow down the bug even more
so that it's easier to find
ource code. I have filed a bug
> > > with the reduced testcase
> > > https://issues.dlang.org/show_bug.cgi?id=19662 .
> >
> > Haha, you were right! It's a compiler bug, another one of those
> > nasty -O -inline bugs. Probably a backend codegen bug. Ran into
&g
On Friday, 8 February 2019 at 21:35:34 UTC, H. S. Teoh wrote:
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via
Digitalmars-d-learn wrote: [...]
I managed to greatly reduce the source code. I have filed a
bug with the reduced testcase
https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via Digitalmars-d-learn wrote:
[...]
> I managed to greatly reduce the source code. I have filed a bug with
> the reduced testcase https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you were right! It's a compiler bug, another one of those
EL% EQU 0 (ECHO No error found) ELSE (EXIT /B 1)
dmd -O -inline -release -boundscheck=off -i app.d -m64
@IF %ERRORLEVEL% EQU 0 (ECHO No error found) ELSE (EXIT /B 1)
@app | FINDSTR /C:"null"
@IF %ERRORLEVEL% EQU 0 (EXIT /B 0) ELSE (EXIT /B 1)
I managed to greatly reduce the source code. I hav
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote:
I will try. However, one last thing - in the example test
scripts, it runs first with one compiler setting (or D version)
and the second time with the other compiler setting (or D
version). But it looks like the exit code of the first run
On Friday, 8 February 2019 at 07:30:41 UTC, Vladimir Panteleev
wrote:
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote:
Does it also work for dub projects?
It will work if you can put all the relevant D code in one
directory, which is harder for Dub, as it likes to pull
dependencies
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote:
Does it also work for dub projects?
It will work if you can put all the relevant D code in one
directory, which is harder for Dub, as it likes to pull
dependencies from all over the place. When "dub dustmite" is
insufficient (as in
py) and delete everything that
isn't directly needed by your code. Of course, at the same time check
also that deleting doesn't change the bug behaviour. If it does, then
whatever you just deleted may possibly be (part of) the cause of the
problem.
Sorry I can't help you with reproducing the prob
On Thursday, 7 February 2019 at 03:50:32 UTC, Vladimir Panteleev
wrote:
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works.
Old thread, but FWIW, such bugs
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works.
Old thread, but FWIW, such bugs can be easily and precisely
reduced with DustMite. In your test script
On Wed, Feb 06, 2019 at 10:37:27PM +, JN via Digitalmars-d-learn wrote:
[...]
> I am not sure if it's a pointer bug. What worries me is that it breaks
> at the start of the program, but uncommenting code at the end of the
> program influences it. Unless there's some crazy reorder
bugs. (Once, a race
condition bug took me almost half a year to fix, because it
only showed up in the customer's live environment and we could
never reproduce it locally. We knew there was a race somewhere,
but it was impossible to locate it. Eventually, by pure
accident, an unrelated code change
y
months just to get a clue on, because it was nigh impossible to track
down where they happened -- the symptoms are too far removed from the
cause. You pretty much have to take a wild guess and get lucky.
They are just as bad as race condition bugs. (Once, a race condition bug
took me almost half a year to fi
code even compiles with these options.
T
No luck. Actually, I avoid in my code pointers in general, I
write my code very "Java-like" with objects everywhere etc. I
gave up on the issue actually, perhaps I am encountering this bug
https://issues.dlang.org/show_bug.cgi?id=16511 in m
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
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
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
On Tue, Dec 18, 2018 at 10:29:07PM +, JN via Digitalmars-d-learn wrote:
> On Monday, 17 December 2018 at 22:22:05 UTC, H. S. Teoh wrote:
> > A less likely possibility might be an optimizer bug -- do you get
> > different results if you add / remove '-O' (and/or '-inline') fr
On Monday, 17 December 2018 at 22:22:05 UTC, H. S. Teoh wrote:
A less likely possibility might be an optimizer bug -- do you
get different results if you add / remove '-O' (and/or
'-inline') from your dmd command-line? If some combination of
-O and -inline (or their removal thereof) "
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 Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
Hey guys,
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works. Unfortunately I am unable to minimize the code,
since it's quite a bit of code, and changing
, 1:Texture2D]
>
> depending on what I change around this code, for example changing it to
>
> writeln(a, " ", b, " ", c);
>
> results in output of:
>
> Texture2D Texture2D Texture2D
> [0:Texture2D, 2:null, 1:null]
Ah, a pointer bug. Lovely. :-/
My f
Hey guys,
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode, debug
works. Unfortunately I am unable to minimize the code, since it's
quite a bit of code, and changing the code changes the bug
occurrence. Basically my
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
here
is a good chance I was wrong about this though since I was adding
a bunch of case statements and code. Given that this occurred
with the other problem might correlate to something else. Not
that big a yet but the first struck me as a big problem if it is
a bug... having code that should e
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
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
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
byte x = 0xF;
ulong y = x >> 60;
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 am using the code
in a template. If I change x to ulong it works as expected.
I've noticed the compiler is not
("a");
}
This code does not even skip the 'int x;' declaration and
initialization - it happens the 2nd time after the goto to W -
but still errors with exactly the same error i.e. 'goto skips
declaration of variable x'. so this is _clearly_ a bug in the
compiler (right?), even more so
two cases that you have to bring up an unrelated
case as a potential cause unless it is relevant.
Remember, I'm showing the starting case that has the bug and
the final case that doesn't... it is simply "mental dustmite"
on the code I have.
You shouldn't assume everyone can't
t; potential cause unless it is relevant.
>
> Remember, I'm showing the starting case that has the bug and the
> final case that doesn't... it is simply "mental dustmite" on the
> code I have.
>
> You shouldn't assume everyone can't comprehend such trivialities.
>
&
A + B and (A + B).
>
> That's not the situation that the OP was describing. If
> adding braces in a situation where the braces have no
> semantic effect has any impact on goto, then it's a compiler
> bug. It's adding a new scope that affects the lifetime of a
> variable who
;>
> >> These two cases are EXACTLY the same semantically. It's like
> >> writing A + B and (A + B).
> >
> > That's not the situation that the OP was describing. If adding
> > braces in a situation where the braces have no semantic effect
> > has any impac
any impact on goto, then it's a compiler bug. It's adding a
new scope that affects the lifetime of a variable whose
declaration is being jumped over by a goto that matters.
I know that you're frustrated, because you've hit a problem
with goto in complex code, and you don't have a simple
e braces have no semantic effect has any impact on goto,
then it's a compiler bug. It's adding a new scope that affects the lifetime
of a variable whose declaration is being jumped over by a goto that matters.
I know that you're frustrated, because you've hit a problem with goto in
complex cod
approach. However, this:
{
if (true) goto X;
T x;
} // x.__dtor
X:
should not error at all, since goto skips both initialization and
use. No one is disputing that. From your posts if I understand
correctly it's that second case that errors in your code. If it
does, there's a bug
rewriting a mathematical
expression using logically valid rules) that involves no real
changes(such as adding scopes), and one fails and the other
doesn't, it means the compiler has a bug.
It's like when people drop parenthesis: (3 + 4)*2 =?= 3 + 4*2.
It's illogical. If the compiler did th
On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis
wrote:
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via
Digitalmars-d-learn wrote:
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
>> And I found a bit strange that in such code, since "x" is
>> never
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via Digitalmars-d-learn
wrote:
> On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
>
> wrote:
> >> And I found a bit strange that in such code, since "x" is
> >> never used, why it isn't skipped.
> >
> > It's skipped right over. The
On Tuesday, 6 November 2018 at 01:05:04 UTC, Neia Neutuladh wrote:
In C++, if you skip over `int i = 10;` it's an error, but not
if you skip over `int i;`.
In fact I agree with that rule more than the D one to be honest.
Since It isn't initialized and never used, I think a warning
should be
On Tuesday, 6 November 2018 at 01:04:46 UTC, Stanislav Blinov
wrote:
...Even if you don't see any explicit use, it doesn't mean the
compiler doesn't see an implicit one.
Sorry I don't think that I follow that. How a compiler could see
an use when it's not being used/invoked on a program like
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
And I found a bit strange that in such code, since "x" is
never used, why it isn't skipped.
It's skipped right over. The goto jumps out of the scope, and
the line with
int x;
is never run. In fact, if you compile with -w
ot;);
> >>
> >> }
> >>
> >> Gives me this error: "source_file.d(4): Error: goto skips
> >> declaration of variable source.main.x at source_file.d(5)"
> >>
> >>
> >> Now, if I add a pair of brackets:
> >&
On Tue, 06 Nov 2018 00:33:56 +, MatheusBN wrote:
> Just to be clear, when you say "x exists at the label Q", you mean at
> the same scope, right?
The same or an outer scope. It's also invalid to write:
goto Y;
{
int x;
{
Y:
}
}
> That's interesting but a bit confusing isn't?
>
>
On Tuesday, 6 November 2018 at 00:38:01 UTC, MatheusBN wrote:
On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov
wrote:
But here it's fine:
void main(){
{
goto Q;
S x;
} // <---
Q:
writeln("a");
}
because goto jumps over both initialization
On Tuesday, 6 November 2018 at 00:13:52 UTC, Stanislav Blinov
wrote:
But here it's fine:
void main(){
{
goto Q;
S x;
} // <---
Q:
writeln("a");
}
because goto jumps over both initialization *and* destruction,
i.e. neither would even be performed.
I see
("a");
}
Gives me this error: "source_file.d(4): Error: goto skips
declaration of variable source.main.x at source_file.d(5)"
Now, if I add a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So
t; }
>
> Gives me this error: "source_file.d(4): Error: goto skips
> declaration of variable source.main.x at source_file.d(5)"
>
>
> Now, if I add a pair of brackets:
>
> void main(){
> {
> goto Q;
> int x;
> }
>
ion of variable source.main.x at source_file.d(5)"
Now, if I add a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So Is this a bug?
No, it's not. Consider replacing that int with a type that
d a pair of brackets:
void main(){
{
goto Q;
int x;
}
Q:
writeln("a");
}
It works. So Is this a bug?
MatheusBN.
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
why the code bellow compiles?
D compilers are allowed to make that an error, but it might not.
With the current implementation,
dmd that.d
will compile, but
dmd -O that.d
will fail with an error. Yes, turning on optimizations
On Monday, 22 October 2018 at 01:39:48 UTC, dangbinghoo wrote:
On Friday, 19 October 2018 at 09:08:32 UTC, Vijay Nayar wrote:
Technically the code you have is syntactically correct. You
are permitted to create a class variable without assigning it
to a class object. (Assigning it to a class
On Friday, 19 October 2018 at 09:08:32 UTC, Vijay Nayar wrote:
Technically the code you have is syntactically correct. You
are permitted to create a class variable without assigning it
to a class object. (Assigning it to a class object would look
like "A a = new A();")
Which section of The
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd
...)
{
void incx(T)(ref T t)
{
++t.x;
}
}
[...]
Not a bug, because when you explicitly specify template
parameters, they are specified in left-to-right order.
You have incx(T, Args...)(ref T t)
t.incx!(1, 2, 3); // 1 => T (error), 2 => Args[0], 3 => Args[1]
incx(t, 1, 2, 3); //
), candidates are:
test.d(3): test.incx(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void incx(Args..., T)(ref T t);
This doesn't seem to work, because:
test.d(3): Error: template `test.incx(Args..., T)(ref T t)` template
tuple parameter must be last one
Hm... didn't
You can simply group them:
t.on!(
handlers!(
"abc", {
writeln("abc");
},
"cde", {
writeln("cde");
}
)
);
handlers!(
"abc", {
writeln("abc");
},
"cde", {
writeln("cde");
}
).bind(t);
On Tuesday, 16 October 2018 at 02:13:21 UTC, Ali Çehreli wrote:
On 10/15/2018 01:36 PM, Márcio Martins wrote:
> Considering that the declaration is legal, and that the
template
> parameter deduction works when Args.length == 0, but stops
working when
> Args.length > 0.
For deduction to work,
On 10/15/2018 01:36 PM, Márcio Martins wrote:
> Considering that the declaration is legal, and that the template
> parameter deduction works when Args.length == 0, but stops working when
> Args.length > 0.
For deduction to work, there must be function arguments. So, just add
Args to the
(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void incx(Args..., T)(ref T t);
This doesn't seem to work, because:
test.d(3): Error: template `test.incx(Args..., T)(ref T t)`
template tuple parameter must be last one
Are you sure it's not a bug? It would be very un-intuitive
On 10/15/18 12:46 PM, Steven Schveighoffer wrote:
Did you mean incx!(T, 1, 2, 3)(t) ?
Sorry, incx!(Test!uint, 1, 2, 3)(t)
-Steve
, 2, 3); // what?
incx(t, 1, 2, 3); // what?
writeln(t.x);
}
test.d(16): Error: template test.incx cannot deduce function from
argument types !(1, 2, 3)(Test!uint), candidates are:
test.d(3): test.incx(T, Args...)(ref T t)
No, not a bug.
I suspect you want this?
void
import std.stdio;
void incx(T, Args...)(ref T t) {
++t.x;
}
static struct Test(T) {
T x;
}
void main() {
Test!uint t;
t.incx(); // works
t.incx!(); // works
incx(t);// works
t.incx!(1, 2, 3); // what?
incx(t, 1, 2, 3); // what?
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
Thank you for explaining all this.
It is frustrating because the behaviour is very counterintuitive.
I will use a workaround for now.
Saurabh
/18 12:55 PM, Jonathan M Davis wrote:
> >>> It's not a bug in writeln. Any time that a range is copied, you must
> >>> not
> >>> do _anything_ else with the original unless copying it is equivalent
> >>> to
> >>> calling save on it,
On 9/6/18 2:52 PM, Jonathan M Davis wrote:
On Thursday, September 6, 2018 12:21:24 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 9/6/18 12:55 PM, Jonathan M Davis wrote:
It's not a bug in writeln. Any time that a range is copied, you must not
do _anything_ else
On Thursday, September 6, 2018 12:21:24 PM MDT Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 9/6/18 12:55 PM, Jonathan M Davis wrote:
> > On Thursday, September 6, 2018 2:40:08 AM MDT Saurabh Das via
> > Digitalmars-d->
> > learn wrote:
> >> Is this a
On 9/6/18 12:55 PM, Jonathan M Davis wrote:
On Thursday, September 6, 2018 2:40:08 AM MDT Saurabh Das via Digitalmars-d-
learn wrote:
Is this a bug with writeln?
void main()
{
import std.stdio, std.range, std.algorithm;
auto a1 = sort([1,3,5,4,2]);
auto a2 = sort([9,8,9
On Thursday, September 6, 2018 2:40:08 AM MDT Saurabh Das via Digitalmars-d-
learn wrote:
> Is this a bug with writeln?
>
> void main()
> {
> import std.stdio, std.range, std.algorithm;
>
> auto a1 = sort([1,3,5,4,2]);
> auto a2 = sort([9,8,9]);
>
On Thursday, 6 September 2018 at 07:37:11 UTC, Simen Kjærås wrote:
On Wednesday, 5 September 2018 at 22:35:16 UTC, SrMordred wrote:
https://run.dlang.io/is/TOTsL4
Yup, that's a bug. Reduced example:
struct S {
int*[1] arr;
}
import std.traits : hasAliasing;
static assert(hasAliasing!S
On Thursday, 6 September 2018 at 09:06:21 UTC, Simen Kjærås wrote:
On Thursday, 6 September 2018 at 08:40:08 UTC, Saurabh Das
wrote:
Is this a bug with writeln?
Yup. What happens is writeln destructively iterates over b[i].
Since b[i] is a forward range, this shouldn't be done
destructively
On Thursday, 6 September 2018 at 08:40:08 UTC, Saurabh Das wrote:
Is this a bug with writeln?
Yup. What happens is writeln destructively iterates over b[i].
Since b[i] is a forward range, this shouldn't be done
destructively. Instead, a copy should be made using b[i].save,
somewhere deep
Is this a bug with writeln?
void main()
{
import std.stdio, std.range, std.algorithm;
auto a1 = sort([1,3,5,4,2]);
auto a2 = sort([9,8,9]);
auto a3 = sort([5,4,5,4]);
pragma(msg, typeof(a1));
pragma(msg, typeof(a2));
pragma(msg, typeof(a3));
auto b = [a1, a2
On Wednesday, 5 September 2018 at 22:35:16 UTC, SrMordred wrote:
https://run.dlang.io/is/TOTsL4
Yup, that's a bug. Reduced example:
struct S {
int*[1] arr;
}
import std.traits : hasAliasing;
static assert(hasAliasing!S);
Issue filed: https://issues.dlang.org/show_bug.cgi?id=19228
Pull
On Wednesday, 5 September 2018 at 22:35:16 UTC, SrMordred wrote:
https://run.dlang.io/is/TOTsL4
I'm not sure I'd consider that a bug, because I do not expect a
static array with 1 element to be equal to a member declaration
even if it's in a strict.
https://run.dlang.io/is/TOTsL4
he slicing that was unsafe, the
AA had nothing to do with it.
Also, one last question: should this issue be reported as a new bug? My
understanding was that @safe code should not allow obtaining references
to expired stack memory, but perhaps this is already a known problem?
I'm happy to file a ne
Thanks again for the quick reply! I have a pretty firm grasp on
what a slice is (array + offset).
Argh! Of course my brain would fail in that sentence! :-) I meant
(pointer + offest).
-Aaron
oring to make changing
AA implementation easier.
Also, one last question: should this issue be reported as a new
bug? My understanding was that @safe code should not allow
obtaining references to expired stack memory, but perhaps this is
already a known problem? I'm happy to file a new bug report
On 8/16/18 2:32 PM, Aaron D. Trout wrote:
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data without question
(even in @safe code), but that will change when dip1000 is
[...]
On Thursday, 16 August 2018 at 17:20:23 UTC, Steven Schveighoffer
wrote:
Yes, this is the effect I would expect.
D has traditionally simply allowed slicing stack data without
question (even in @safe code), but that will change when
dip1000 is fully realized. It will be allowed, but
On 8/16/18 12:51 PM, Aaron D. Trout wrote:
Hello all! I'm a mathematician at Chatham University in Pittsburgh, PA
(USA). I use D for research, and I'm a frequent lurker on the forums. I
think I found a bug, but I want to make sure I'm not just doing
something silly. (I'm happy to file
Hello all! I'm a mathematician at Chatham University in
Pittsburgh, PA (USA). I use D for research, and I'm a frequent
lurker on the forums. I think I found a bug, but I want to make
sure I'm not just doing something silly. (I'm happy to file a
bugzilla issue if it turns out to be a legitimate
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov
[ZombineDev] wrote:
It's not a bug, it's all about how the type system is set up.
The type of an array literal expression like `[1, 2, 3]` is
`int[]` (a slice of an array of ints), so no matter if you do:
auto readonly(T)(const(T
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov
[ZombineDev] wrote:
https://run.dlang.io/is/iD9ydu
I made a typo in one of the comments. Here's the fixed version:
https://run.dlang.io/is/HRqYcZ
On Tuesday, 14 August 2018 at 17:49:32 UTC, Mike Franklin wrote:
On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote:
FYI: staticArray will be part of 2.082, it already works with
dmd-nightly:
That just seems wrong. Isn't the fact that `staticArray` is
needed a bug in the compiler? I
On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote:
FYI: staticArray will be part of 2.082, it already works with
dmd-nightly:
That just seems wrong. Isn't the fact that `staticArray` is
needed a bug in the compiler? I think the compiler could have
lowered to something like
301 - 400 of 1912 matches
Mail list logo
