On Tuesday, 14 August 2018 at 16:31:38 UTC, Paul Backus wrote:
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
Workaround:
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
Workaround: https://run.dlang.io/is/NZykl0
Source:
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
You can use `static immutable` as a workaround for now:
terC
Yes. https://issues.dlang.org/show_bug.cgi?id=19169
This seems to be because dynamic array literals are allocated by
default. So that is possibly not a bug, per se but the error
message is definitely not helpful.
On Tuesday, 14 August 2018 at 13:01:57 UTC, learnfirst1 wrote:
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
Yes. https://issues.dlang.org/show_bug.cgi?id=19169
enum string[] a = ["a"];
extern(C) void main() {
int i = 0;
auto s = a[i];
}
---
Error: TypeInfo cannot be used with -betterC
On Friday, 10 August 2018 at 12:05:52 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote:
If you try the same without the mixin template, you'll see that
it doesn't work:
struct Test {
extern(C) pragma(crt_constructor) static void init(){ // work
On Friday, 10 August 2018 at 11:17:10 UTC, learnfirst1 wrote:
I think the static extern(C) nested function should just work
like global extern(C) function. DMD still report missing
symbols. Or I am wrong about this ?
template G(){
static extern(C) pragma(crt_constructor) void
On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote:
Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=19153
template G(){
pragma(crt_constructor) static extern(C) void init(){}
}
void main(){
mixin G
On Friday, 10 August 2018 at 10:24:55 UTC, Simen Kjærås wrote:
On Friday, 10 August 2018 at 08:31:21 UTC, learnfirst1 wrote:
The correct behavior would be for the compiler to show the
latter error message for a mixin'd function as well.
Filed a bug:
https://issues.dlang.org/show_bug.cgi?id
r message for a mixin'd function as well.
Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=19153
--
Simen
[0]: from https://dlang.org/spec/attribute.html#linkage:
Note that extern(C) can be provided for all types of
declarations, including struct or class, even though there is no
corresp
#!/usr/bin/env rdmd
import core.stdc.stdio;
template G(size_t line = __LINE__, A...){
int i = 3;
static extern(C) pragma(crt_constructor) void init2(){
printf("init: %d\n", line);
}
}
pragma(crt_constructor) extern(C) void init1(){
printf("init
ode compiles. However, for the package
> protection it may happen that a subclass is in the same package
> (and just happened to me).
>
> Should I file a bug or is there a reason for such behavior?
I don't rememeber the reasoning at the moment, but it's most definitely not
a bug and is on pu
of
parent class, so there's no need in making it virtual. For
protected/public the code compiles. However, for the package
protection it may happen that a subclass is in the same package
(and just happened to me).
Should I file a bug or is there a reason for such behavior?
On Mon, Apr 02, 2018 at 10:26:32AM +, RazvanN via Digitalmars-d-learn wrote:
> Hi all,
>
> Let's say we have this code:
>
> struct B
> {
> int a;
> this(int a) immutable
> {
> this.a = 7;
> }
>
> this(int a)
> {
> this.a = 10;
> }
> }
>
> void
On Monday, 2 April 2018 at 11:41:55 UTC, Eduard Staniloiu wrote:
On Monday, 2 April 2018 at 10:26:32 UTC, RazvanN wrote:
[...]
The compiler does an implicit conversion from the type
`immutable B`
to the type `B`. It is able to do safely do so because `struct
B` has only
value types that
On Monday, 2 April 2018 at 10:26:32 UTC, RazvanN wrote:
Hi all,
Let's say we have this code:
struct B
{
int a;
this(int a) immutable
{
this.a = 7;
}
this(int a)
{
this.a = 10;
}
}
void main()
{
B a = immutable B(2);
writeln(a.a);
a.a =
Hi all,
Let's say we have this code:
struct B
{
int a;
this(int a) immutable
{
this.a = 7;
}
this(int a)
{
this.a = 10;
}
}
void main()
{
B a = immutable B(2);
writeln(a.a);
a.a = 4;
immutable B a2 = immutable B(3);
On 03/17/2018 11:36 AM, Jonathan wrote:
`(a+b)&0xff` What is this syntax?! Could you give a link to this in the
D documentation?
Here is my description of bitwise AND:
http://ddili.org/ders/d.en/bit_operations.html#ix_bit_operations.&,%20bitwise%20and
The section titled "Masking" on the
On Saturday, 17 March 2018 at 18:56:55 UTC, Dominikus Dittes
Scherkl wrote:
On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote:
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe
wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend
wrote:
I don't care if my
On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote:
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe
wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend
wrote:
I don't care if my computer needs to do math on a 4 byte
basis, I'm not writing assembly.
x86
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend
wrote:
I don't care if my computer needs to do math on a 4 byte
basis, I'm not writing assembly.
x86 actually doesn't need to do math that way, if you were
writing
On 02/19/2018 05:33 AM, rikki cattermole wrote:
https://dlang.org/phobos/std_experimental_checkedint.html#.Checked.min
Accompanying presentations:
DConf 2017: https://www.youtube.com/watch?v=29h6jGtZD-U
Google Tel Aviv: https://www.youtube.com/watch?v=es6U7WAlKpQ
Andrei likes the
for
+=, -=, *=, /=, %=, ^^=, &=, |=, ^=, <<=, >>=, and >>>=. But
since init is 0, += works:
Ah, thanks. Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=18471
--
Simen
I think this is a design choice, it's too obvious to be an
omission (it's even documented that opAssign is like the ctor).
I
orks:
Ah, thanks. Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=18471
--
Simen
On Monday, 19 February 2018 at 13:51:50 UTC, Simen Kjærås wrote:
On Monday, 19 February 2018 at 13:33:34 UTC, rikki cattermole
wrote:
https://dlang.org/phobos/std_experimental_checkedint.html#.Checked.min
Can't seem to get that to work, so I assumed it's not meant to
be used that way:
On Monday, 19 February 2018 at 13:33:34 UTC, rikki cattermole
wrote:
https://dlang.org/phobos/std_experimental_checkedint.html#.Checked.min
Can't seem to get that to work, so I assumed it's not meant to be
used that way:
import std.experimental.checkedint;
struct MyHook {
enum min(T) =
On 19/02/2018 1:24 PM, Simen Kjærås wrote:
On Monday, 19 February 2018 at 12:58:45 UTC, Marc wrote:
I'm pretty sure something could be done with Ada's type range but what
we could do using D?
We can easily define a range type in D. The simple example below
probably has awful performance and
On Monday, 19 February 2018 at 12:58:45 UTC, Marc wrote:
I'm pretty sure something could be done with Ada's type range
but what we could do using D?
We can easily define a range type in D. The simple example below
probably has awful performance and many holes, but outlines the
basic idea. It
I'm pretty sure something could be done with Ada's type range but
what we could do using D?
On Friday, 16 February 2018 at 13:57:07 UTC, Steven Schveighoffer
wrote:
You have a pretty good minimal test, put that in bugzilla along
with the forum thread link and all the info we know. Mark it as
a dmd bug, regression, along with the version where it
regressed (2.076.1), and I would tag
found something very weird.
If you pragma(msg, isInputRange!(typeof(dgs))); inside your file, then
it compiles (and prints true for that pragma).
Makes no sense at all. Definitely seems like a compiler bug. A
pragma(msg) shouldn't affect the outcome.
ok so what should the bug report look like
pragma(msg, isInputRange!(typeof(dgs))); inside your
file, then it compiles (and prints true for that pragma).
Makes no sense at all. Definitely seems like a compiler bug. A
pragma(msg) shouldn't affect the outcome.
-Steve
ok so what should the bug report look like?
.front
onlineapp.d(7): Error: template instance
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused it.
Looking at "moveAll" which is the one that causes the erro
p.d(7): Error: template instance
std.algorithm.mutation.remove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused
it.
Looking at "moveAll" which is the one that causes the error, no
chang
emove!(cast(SwapStrategy)2, void
delegate(void*)[], int) error instantiating
-
It's definitely a bug, the question is what change has caused it.
On Friday, 16 February 2018 at 11:45:21 UTC, arturg wrote:
this code fails to compile:
void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();
if you comment out dgs.writeln; it works as expected,
it works if you use other types
this code fails to compile:
void delegate(void*) dg;
void delegate(void*)[] dgs = [dg, dg, dg];
dgs.writeln;
dgs.remove(1).writeln();
if you comment out dgs.writeln; it works as expected,
it works if you use other types then void*:
void delegate(int*) dg;
void
as static assertion fails. Making the filed a
public makes it compile properly. Should I file a bug or is by
design?
It's definitely a bug!
as static assertion fails. Making the filed a
public makes it compile properly. Should I file a bug or is by
design?
getSymbolsByUDA seems to have some visibility thing going on.
Related to https://issues.dlang.org/show_bug.cgi?id=17973
perhaps? Though that only gives deprecation warnings
properly. Should I file a bug or is by
design?
On Saturday, January 27, 2018 09:35:05 Oleksii Skidan via Digitalmars-d-
learn wrote:
> On Saturday, 27 January 2018 at 08:18:07 UTC, thedeemon wrote:
> > On Friday, 26 January 2018 at 21:17:14 UTC, Oleksii Skidan
> >
> > wrote:
> >> struct Game {
> >>
> >> Triangle player = new Triangle;
> >
On Saturday, 27 January 2018 at 08:18:07 UTC, thedeemon wrote:
On Friday, 26 January 2018 at 21:17:14 UTC, Oleksii Skidan
wrote:
struct Game {
Triangle player = new Triangle;
When you initialize a struct member like this, compiler tries
to calculate the initial value and remember it as
On Friday, 26 January 2018 at 21:17:14 UTC, Oleksii Skidan wrote:
struct Game {
Triangle player = new Triangle;
When you initialize a struct member like this, compiler tries to
calculate the initial value and remember it as data, so each time
such struct is constructed the data is just
iangle player = new Triangle;
void tick() {
player.tick();
}
}
void main()
{
Game game;
game.tick();
}
```
Is that my bug (highest probability here) or a compiler bug? I'm
confused, since the following `main` function compiles
successfully:
```
void main()
{
Tri
On Tuesday, 31 October 2017 at 04:27:27 UTC, Joel wrote:
Ok, thanks guys.
why not throw in some UFCS too...just because you can ;-)
import std.stdio;
void main()
{
int foo;
if (foo.bar != 0) // would be nice if I could do: (int
foo.bar != 0)
{
throw new
Ok, thanks guys.
On Tuesday, 31 October 2017 at 04:08:12 UTC, Joel wrote:
if (int bar = foo() != 0) {
Not a bug, but I do think it is an iffy design.
That is more like:
int bar;
if(bar = (foo() != 0))
so the foo != 0 is evaluated first, which ends up being boolean
true or false, then THAT true
On Tuesday, October 31, 2017 04:08:12 Joel via Digitalmars-d-learn wrote:
> The following code assert fails (bar == 1, not -10!). I've wasted
> a bit of time because of this happening.
>
> void main() {
> if (int bar = foo() != 0) {
> assert(bar == -10);
> }
> }
>
> auto foo() {
>
The following code assert fails (bar == 1, not -10!). I've wasted
a bit of time because of this happening.
void main() {
if (int bar = foo() != 0) {
assert(bar == -10);
}
}
auto foo() {
return -10;
}
and see if your change does the fix.
If it does, it will be the best timed bug fix ever :)
Turned out to be more fiddly than I hoped because of unicode.
Atila did the work, but it's awaiting a pre-review to be sure
it's okay before submitting. In case it's helpful in the
meantime, it seems
oops, it was my fault. sorry for noise. my apologies to ElementType ))
https://run.dlang.io/is/duecIS
, it will be the best timed bug fix ever :)
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
I've got a github project and using DUB with DMD and I keep
running into this problem. I've tried deleting the entire
...\AppData\Roaming\dub\packages folder, but the
problem repeats the very next build attempt.
[...]
See my
On Friday, 6 October 2017 at 09:12:09 UTC, Mike Parker wrote:
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
AppData/Roaming/dub/packages, create a new directory off C:
(say, C:\dub, manually fetch the packages you need into that
directory and use `dub add-local` on them
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote:
With writing files, that's usually a permissions thing? But
all the other 8 packages build fine?
Note: I had a similar problem with derelict-assimp3 package, so
I went to an entirely different system and cloned my project.
I've got a github project and using DUB with DMD and I keep
running into this problem. I've tried deleting the entire
...\AppData\Roaming\dub\packages folder, but the
problem repeats the very next build attempt.
Fetching derelict-util 2.0.6 (getting selected version)...
Fetching derelict-ft
On Monday, 2 October 2017 at 09:34:29 UTC, Andrea Fontana wrote:
Anyway: you cant put a default destructor on struct
True. In which case you should either @disable this() (which
presents its own set of issues) or hide b behind a @property
function, something like:
struct S {
B _b;
On Monday, 2 October 2017 at 09:08:59 UTC, Biotronic wrote:
Not knowing what you're attempting to do, I'm not sure how to
fix your problem. But if what I've described above does indeed
cover it, initializing b in the constructor is the way to get
it to work.
--
Biotronic
Obviusly real
On Monday, 2 October 2017 at 08:47:47 UTC, Andrea Fontana wrote:
Why this code doesn't write two identical lines?
https://dpaste.dzfl.pl/e99aad315a2a
Andrea
A reduced example of where it goes wrong:
class B {}
struct A {
B b = new B;
}
unittest {
A a1, a2;
assert(a1 == a2);
}
Why this code doesn't write two identical lines?
https://dpaste.dzfl.pl/e99aad315a2a
Andrea
On 9/26/17 8:44 AM, drug wrote:
26.09.2017 15:16, Steven Schveighoffer пишет:
Nullable!(char[]) x;
writeln(x); // Nullable.null;
static struct Foo { Nullable!(char[]) x; }
Foo foo;
writeln(foo); // error
So in one context, printing a nullable char[] works exactly as
expected. In another
26.09.2017 15:16, Steven Schveighoffer пишет:
Yes, that is the bug, as I said at the end of my message. But you had
confused the issue by showing that "hey bar.foo isn't null!" which had
nothing to do with the bug. It wasn't null, and wasn't improperly being
treated as null. You
On 9/26/17 3:13 AM, drug wrote:
25.09.2017 22:58, Steven Schveighoffer пишет:
First up, the non-bug:
You wrote:
writeln(bar.foo.isNull); // false
writeln(bar.foo); // error
But bar.foo is this:
struct Foo
{
Nullable!(char[2]) value;
}
And bar.foo is nullable itself. It's a nullable
25.09.2017 22:58, Steven Schveighoffer пишет:
First up, the non-bug:
You wrote:
writeln(bar.foo.isNull); // false
writeln(bar.foo); // error
But bar.foo is this:
struct Foo
{
Nullable!(char[2]) value;
}
And bar.foo is nullable itself. It's a nullable!Foo.
It's a Nullable!Foo
On 9/25/17 2:03 PM, drug wrote:
https://run.dlang.io/is/pZwsoX
As I can see std.format.formatElement thinks Nullable!Foo is not null,
try to get its value but it is null so fail?
OK, so I was confused quite a bit.
There are 2 problems. One is a bug, one is not.
First up, the non-bug:
You
https://run.dlang.io/is/pZwsoX
As I can see std.format.formatElement thinks Nullable!Foo is not null,
try to get its value but it is null so fail?
25.09.2017 20:47, Adam D. Ruppe пишет:
On Monday, 25 September 2017 at 17:44:54 UTC, drug wrote:
https://run.dlang.io/is/uk0CMC
You didn't initialize it. It's not null, but it also isn't a valid
character.
but exception is caused by using `get` on null Foo instance, not by
invalid character
On 9/25/17 1:44 PM, drug wrote:
https://run.dlang.io/is/uk0CMC
Definitely a bug.
-Steve
On Monday, 25 September 2017 at 17:44:54 UTC, drug wrote:
https://run.dlang.io/is/uk0CMC
You didn't initialize it. It's not null, but it also isn't a
valid character.
D initializes chars to 0xff, which is an invalid char.
Perhaps the Nullable one should have initialized to null but
https://run.dlang.io/is/uk0CMC
On Thursday, 7 September 2017 at 16:08:53 UTC, Piotr Mitana wrote:
main.d(17): Error: one path skips constructor
main.d(15): Error: return without calling constructor
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Throwing_exception_in_constructor_28995.html
do I need the constructor call, if I throw the exception
anyway? Is this a bug?
This seems likely a bug, my understanding of this error is for
class inheritance, where it must call the super constructor for
all code paths to create the base class. With a struct the
compiler always has
main()
{
A(2004, 43);
A("2004-43");
}
===
This throws a compilation error:
main.d(17): Error: one path skips constructor
main.d(15): Error: return without calling constructor
Why do I need the constructor call, if I throw the exception
anyway? Is this a bug?
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
interface I
{
void Go(T)(S!T s);
static final I New()
{
return new C();
}
}
abstract class A : I
{
}
class C : A
{
void Go(T)(S!T s)
{
On Monday, 4 September 2017 at 03:08:50 UTC, EntangledQuanta
wrote:
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September
On Monday, 4 September 2017 at 01:50:48 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September
On Sunday, 3 September 2017 at 23:25:47 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2
On Sunday, 3 September 2017 at 11:48:38 UTC, Moritz Maxeiner
wrote:
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC,
EntangledQuanta wrote:
[...]
The
On Sunday, 3 September 2017 at 04:18:03 UTC, EntangledQuanta
wrote:
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
[...]
The contexts being independent of each other doesn't change
that we would still
On Sunday, 3 September 2017 at 02:39:19 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC,
EntangledQuanta wrote:
On Friday, 1
On Saturday, 2 September 2017 at 23:12:35 UTC, EntangledQuanta
wrote:
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being
On Saturday, 2 September 2017 at 21:19:31 UTC, Moritz Maxeiner
wrote:
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic
functions in C#. Unfortunately C#
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips
wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so
many other issues where Generics
needed which would generate the
functions and you hit a Visual D with the new static foreach.
This sentence makes no sense. "hit a Visual D" what? Do you mean
bug? If that is the case, how is that my fault? Amd I suppose to
know off the bat that an access violation is caused b
On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta
wrote:
Regardless of the implementation, the idea that we should throw
the baby out with the bathwater is simply wrong. At least there
are a few who get that. By looking in to it in a serious manner
an event better solution might
On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips wrote:
I've love being able to inherit and override generic functions
in C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
I've love being able to inherit and override generic functions in
C#. Unfortunately C# doesn't use templates and I hit so many
other issues where Generics just suck.
I don't think it is appropriate to dismiss the need for the
compiler to generate a virtual function for every instantiated T,
Nothing new here but I almost fell prey to this bug today. Spot the bug:
import std.stdio;
import std.range;
int[3] bar() {
return [ 1, 2, 3 ];
}
auto foo() {
auto a = bar();
return zip(a[], a[]);
}
void main() {
writeln(foo());
}
In the real code, bar() was a call
This happens when building, not running. This might be a Visual D
issue as when I use dmd from the command line, it works fine ;/
On Friday, 1 September 2017 at 19:25:53 UTC, Adam D Ruppe wrote:
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means
you didn't new the class...
No, that is the
On Friday, 1 September 2017 at 18:17:22 UTC, EntangledQuanta
wrote:
I get an access violation, changed the code to
What is the rest of your code? access violation usually means you
didn't new the class...
On Friday, 1 September 2017 at 15:24:39 UTC, Adam D. Ruppe wrote:
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list
of types
}
static foreach is now in the new release! You can now do stuff
like:
---
alias I(A...) = A;
interface Foo {
static foreach(T; I!(int, float))
void set(T t); // define virt funcs for a list of
types
}
class Ass : Foo {
static foreach(T; I!(int, float))
On Thursday, 31 August 2017 at 15:48:12 UTC, EntangledQuanta
wrote:
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all
On Thursday, 31 August 2017 at 10:34:14 UTC, Kagamin wrote:
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
Then, by all means, genius!
On Thursday, 31 August 2017 at 00:49:22 UTC, EntangledQuanta
wrote:
I've already implemented a half ass library solution.
It can be improved alot.
On 08/30/2017 05:49 PM, EntangledQuanta wrote:
> The compiler can and should do this!
Yes, the compiler can do it for each compilation but there is also the
feature called /separate compilation/ that D supports. With separate
compilation, there would potentially be multiple different and
On Wednesday, 30 August 2017 at 22:52:41 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 August 2017 at 20:47:12 UTC, EntangledQuanta
wrote:
This is quite surprising!
In the new version pending release (scheduled for later this
week), we get a new feature `static foreach` that will let you
loop
401 - 500 of 1912 matches
Mail list logo
