On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially
The D unittest feature has been a mixed bag from the beginning
for me.
When a codebase starts to consider to parallelize the unittests
it's has in many cases become a very expensive to make this
change. If order of execution was not guaranteed this would force
coders to make a better long term
On Thursday, 1 May 2014 at 02:36:23 UTC, Walter Bright wrote:
On 4/30/2014 6:50 PM, deadalnix wrote:
On Thursday, 1 May 2014 at 01:20:37 UTC, Walter Bright wrote:
A link to your previous comment would be useful.
I've written several proposal regarding this. Please at least
read them as what
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
Now some sample code/explanation to get it better.
Isolated in a proposal adapted from an experiment made in C# for
D. It introduces a
On Friday, 2 May 2014 at 04:28:26 UTC, Ola Fosheim Grøstad wrote:
On Friday, 2 May 2014 at 03:04:39 UTC, Jason Spencer wrote:
If we don't want to consider how we can accommodate both camps
here, then I must at least support Jonathan's modest
suggestion that parallel UTs require active
On Thursday, 1 May 2014 at 20:03:03 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 12:52 PM, Nordlöw wrote:
into a class. I'm inclined to say that we should outright
prohibit that,
That can't happen.
Why is that?
(1) Too much breakage, (2) would disallow a ton of correct
code, (3) no
On Friday, 2 May 2014 at 00:45:42 UTC, Andrei Alexandrescu wrote:
Here's where the point derails. A struct may be preexisting;
the decision to define a destructor for it and the decision to
use polymorphism for an object that needs that structure are
most of the time distinct.
Andrei
Sheep
On Friday, 2 May 2014 at 06:51:49 UTC, deadalnix wrote:
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
Now some sample code/explanation to get it better.
Isolated in a proposal
On Friday, 2 May 2014 at 00:22:14 UTC, deadalnix wrote:
2. Creating a new name lookup mechanism is the kind of idea
that sound good but ends up horribly backfiring. There is all
kind of implications and it affect every single identifier
resolution. You don't want to mess with that (especially
On 5/2/2014 12:34 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
The implications with this DIP is that all library authors will have to follow a
convention of having all C++ dependencies in a module named cpp in order to
have a fake way of specifying fully qualified C++
On Thursday, 1 May 2014 at 21:29:19 UTC, Andrei Alexandrescu
wrote:
On 5/1/14, 1:19 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 01, 2014 at 01:03:06PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 5/1/14, 12:52 PM, Nordlöw wrote:
into a class. I'm inclined to say that we
On 5/1/2014 11:51 PM, deadalnix wrote:
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
It's nearly the same as http://wiki.dlang.org/DIP29 except that DIP29 tries to
use a library
On Friday, 2 May 2014 at 09:05:13 UTC, Walter Bright wrote:
On 5/1/2014 11:51 PM, deadalnix wrote:
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
It's nearly the same as
On Friday, 2 May 2014 at 07:44:50 UTC, Walter Bright wrote:
Not at all, any more than you have to do that for C names.
The difference is that C names tend to have their namespace
embedded:
framework_structname_function()
On 5/2/2014 2:24 AM, deadalnix wrote:
DIP29 is not safe,
How so?
does not help to construct immutables,
immutable p = new int;
works.
is not inferred,
I'm surprised you'd say that, most of it is about inferring uniqueness.
do not provide aliasing infos for the optimizer,
I like it a lot, as it solves several problems elegantly! Some
comments inline...
On Friday, 2 May 2014 at 06:51:49 UTC, deadalnix wrote:
An isolated is consumed when:
- it is returned
- it is passed as argument
- it is assigned to another island
Assignment and passing to a scope variable
On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via
Digitalmars-d wrote:
The thing is, GC is a terrible and unreliable method of
managing
non-memory resource lifetimes. Destructors for GC objects are
not
On Friday, 2 May 2014 at 06:57:46 UTC, w0rp wrote:
You know, executing batches of tests in multiple processes
could be a good compromise. You might still run into filesystem
issues, but if you run a series of tests with a number of
processes at the same time, you can at least guarantee that
On Thursday, 1 May 2014 at 18:38:15 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 17:04:53 UTC, Xavier Bigand wrote:
Le 01/05/2014 16:01, Atila Neves a écrit :
On Thursday, 1 May 2014 at 11:44:12 UTC, w0rp wrote:
On Thursday, 1 May 2014 at 11:05:55 UTC, Jacob Carlborg
wrote:
On 2014-04-30
On Thursday, 1 May 2014 at 11:17:10 UTC, Temtaime wrote:
Hi everyone.
I think it's need to have -w64(or other name, offers ?) flag
that warns if code may not compile on other archs.
Example:
size_t a;
uint b = a; // ok on 32 without a warning but fail on 64 with
error
And on 32 with -w64
Walter Bright:
You've already got it working with version, that's what version
is for. Why add yet another way to do it?
Because I'd like something better. It's an idiom that I have used
many times (around 15-20 times). I'd like the compiler (or build
tool) to avoid me to specify two times
On Thursday, 1 May 2014 at 11:17:10 UTC, Temtaime wrote:
Hi everyone.
I think it's need to have -w64(or other name, offers ?) flag
that warns if code may not compile on other archs.
Example:
size_t a;
uint b = a; // ok on 32 without a warning but fail on 64 with
error
And on 32 with -w64
Temtaime:
I think it's need to have -w64(or other name, offers ?) flag
that warns if code may not compile on other archs.
Some of the things it has to guard against:
void main() {
size_t x;
ptrdiff_t y;
uint r1 = x; // warn
int r2 = x; // warn
uint r3 = y; // warn
Any one interested in writing a little paper about D language
used for medium-integrity software systems? :-)
http://lambda-the-ultimate.org/node/4943
http://sigada.org/conf/hilt2014/
While D isn't Ada, I think it's plenty better than using C plus
the handcuffs
On Fri, 02 May 2014 02:51:47 -0400, deadalnix deadal...@gmail.com wrote:
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
Now some sample code/explanation to get it better.
Isolated
On Fri, 02 May 2014 01:22:12 +0100, deadalnix deadal...@gmail.com wrote:
On Thursday, 1 May 2014 at 10:03:21 UTC, Regan Heath wrote:
On Wed, 30 Apr 2014 20:56:15 +0100, Timon Gehr timon.g...@gmx.ch
wrote:
If this is a problem, I guess the most obvious alternatives are to:
1. Get rid of
On Thu, 01 May 2014 21:44:10 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/1/2014 5:33 PM, deadalnix wrote:
On Thursday, 1 May 2014 at 18:44:36 UTC, Walter Bright wrote:
On 4/27/2014 12:54 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Now with pull request:
On Fri, 02 May 2014 09:50:07 -0400, Meta jared...@gmail.com wrote:
On Friday, 2 May 2014 at 06:51:49 UTC, deadalnix wrote:
An isolated is consumed when:
- it is returned
- it is passed as argument
- it is assigned to another island
This will not work well with UFCS.
isolated int[] ints =
On Friday, 2 May 2014 at 06:51:49 UTC, deadalnix wrote:
An isolated is consumed when:
- it is returned
- it is passed as argument
- it is assigned to another island
This will not work well with UFCS.
isolated int[] ints = new int[](10);
//put looks like a member function, but
//this
On 02/05/14 02:22, H. S. Teoh via Digitalmars-d wrote:
I was reading this article of Walter's:
http://www.drdobbs.com/cpp/the-x-macro/228700289
Which is a neat trick that I wish I'd known back when I was writing
C/C++. But the thought crossed my mind: what's the D equivalent of the X
On 01/05/14 21:55, Marc Schütz schue...@gmx.net wrote:
You're probably right. I thought that changed in a recent release, but
can't find it anymore.
I don't know. I wouldn't trust it. It's the behavior in Rails 3. I
haven't used Rails 4 yet.
--
/Jacob Carlborg
On Friday, 2 May 2014 at 13:26:00 UTC, bearophile wrote:
Any one interested in writing a little paper about D language
used for medium-integrity software systems? :-)
http://lambda-the-ultimate.org/node/4943
http://sigada.org/conf/hilt2014/
While D isn't Ada, I think it's plenty better than
On 5/1/14, 8:04 PM, Jason Spencer wrote:
On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
I'll be blunt. What you say is technically sound (which is probably
why you believe it is notable)...
Well, I suppose that's not the MOST insulting brush-off I could hope
for, but it
On 5/1/14, 8:04 PM, Jason Spencer wrote:
On Thursday, 1 May 2014 at 21:40:38 UTC, Andrei Alexandrescu wrote:
I'll be blunt. What you say is technically sound (which is probably
why you believe it is notable)...
Well, I suppose that's not the MOST insulting brush-off I could hope
for, but it
On 5/2/14, 1:34 AM, Paolo Invernizzi wrote:
On Thursday, 1 May 2014 at 21:29:19 UTC, Andrei Alexandrescu wrote:
On 5/1/14, 1:19 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 01, 2014 at 01:03:06PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 5/1/14, 12:52 PM, Nordlöw wrote:
On 5/2/14, 12:07 AM, deadalnix wrote:
The breakage in the proposal is already massive. For instance, GtkD
won't work. And other example have been presented.
Yah, prolly we can't go that far. -- Andrei
On 5/2/14, 2:24 AM, deadalnix wrote:
On Friday, 2 May 2014 at 09:05:13 UTC, Walter Bright wrote:
On 5/1/2014 11:51 PM, deadalnix wrote:
First the original post I made on this forum :
http://forum.dlang.org/thread/kluaojijixhwigouj...@forum.dlang.org#post-kluaojijixhwigoujeip:40forum.dlang.org
On 5/2/14, 3:09 AM, Marc Schütz schue...@gmx.net wrote:
On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via
Digitalmars-d wrote:
The thing is, GC is a terrible and unreliable method of managing
non-memory
On 5/2/14, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
So now it looks like dynamic arrays also can't contain structs with
destructors :o). -- Andrei
I suggest tracking these ideas on a wiki page so we don't lose track
of what the latest proposal is (we'll run in
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
On 5/2/14, 3:09 AM, Marc Schütz schue...@gmx.net wrote:
On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via
Digitalmars-d
wrote:
On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via
Digitalmars-d wrote:
The thing is,
Hello,
I'm currently doing a nice optimization in the tracing code: I use the
same bit (per block) to indicate this memory is allocated and this
memory is marked as used during tracing.
The way the trick works is, at the beginning of a collection the GC
marks all of its memory as
On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu
wrote:
I think there's no need to argue that in this community. The GC
never guarantees calling destructors even today, so this
decision would be just a point in the definition space (albeit
an extreme one).
I think I (we) need
On Thu, 01 May 2014 11:17:09 +
Temtaime via Digitalmars-d digitalmars-d@puremagic.com wrote:
Hi everyone.
I think it's need to have -w64(or other name, offers ?) flag that
warns if code may not compile on other archs.
Example:
size_t a;
uint b = a; // ok on 32 without a warning but
On 5/2/14, 9:04 AM, fra wrote:
On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
I think there's no need to argue that in this community. The GC never
guarantees calling destructors even today, so this decision would be
just a point in the definition space (albeit an
On 2014-05-02 17:38, Marc Schütz schue...@gmx.net wrote:
But my main point was actually this:
Don't disallow destructors on classes just because they are classes, but
disallow them when they are not guaranteed to be called (or calling them
is troublesome because of multi-threading), i.e. GC.
On Friday, 2 May 2014 at 14:59:50 UTC, Andrei Alexandrescu wrote:
I need to make an amend to this because indeed it's more than 2
std deviations away from niceness: I have a long history of
ideas with a poor complexity/usefulness ratio, and I now wish
I'd received such a jolt. -- Andrei
I
Well, in a 64-bit address space, the false pointer issue is almost
mute, the issue comes in when you try to apply this design to 32-bit,
where the false pointer issue is more prevelent. Is the volume of
memory saved by this really worth it?
Another thing to consider is that this makes it
On Friday, 2 May 2014 at 15:55:06 UTC, Andrei Alexandrescu wrote:
Hello,
I'm currently doing a nice optimization in the tracing code: I
use the same bit (per block) to indicate this memory is
allocated and this memory is marked as used during tracing.
The way the trick works is, at the
On Fri, 02 May 2014 11:55:11 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Hello,
I'm currently doing a nice optimization in the tracing code: I use the
same bit (per block) to indicate this memory is allocated and this
memory is marked as used during tracing.
The
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
I think one of the great things about Rails and Ruby is all the
libraries and plugins that are available. If I want to do
something, in RoR there's a big chance there's already a
library for that. In D, there's a big chance I
On Friday, 2 May 2014 at 09:25:34 UTC, Ola Fosheim Grøstad wrote:
On Friday, 2 May 2014 at 07:44:50 UTC, Walter Bright wrote:
Not at all, any more than you have to do that for C names.
The difference is that C names tend to have their namespace
embedded:
framework_structname_function()
On Fri, 02 May 2014 13:26:41 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Why not keep the 3 states, but just treat unmarked blocks as free? Then
the next time you go through tracing, change the bit to free if it was
already marked.
Sorry, if it was already *unmarked* (or
On 5/2/14, 10:15 AM, Orvid King via Digitalmars-d wrote:
Well, in a 64-bit address space, the false pointer issue is almost
mute, the issue comes in when you try to apply this design to 32-bit,
where the false pointer issue is more prevelent. Is the volume of
memory saved by this really worth
On 5/2/14, 10:12 AM, Marc Schütz schue...@gmx.net wrote:
If destructors are still going to be called (see other thread), this
trick is dangerous, because the resurrected objects might later on be
destroyed again (double free).
Yah, forgot to mention this trick is only applicable to what I
On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
To make this more useful, turn it into a requirement. It gets
us deterministic destruction for reference types. Example:
...
isolated tmp = new Tempfile();
// use tmp
...
// tmp is guaranteed to
On 5/2/14, 10:26 AM, Steven Schveighoffer wrote:
False pointers are less of a problem in 64-bit code, but you can run
into worse issues. If you are not zeroing the memory when deallocating,
then if it mysteriously comes alive again, it has the ghost of what
could be a pointer to other code. Your
On 5/2/14, 10:33 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 13:26:41 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Why not keep the 3 states, but just treat unmarked blocks as free?
Then the next time you go through tracing, change the bit to free if
it was already marked.
On Fri, 02 May 2014 14:00:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 10:33 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 13:26:41 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Why not keep the 3 states, but just treat unmarked blocks as
On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
That's true, but it is also a breaking change, because then
suddenly some variables aren't writable anymore (or
alternatively, the compiler would have to analyse all future
uses of the variable first to see whether it can be inferred
Correct me if I'm wrong here, but this seems really similar to
how Rust does owned pointers and move semantics. Or is there a
large conceptual difference between the two that I'm missing?
I believe that the issues that people are bringing up with bad
interaction with UFCS, and losing isolated
On 5/2/14, 11:07 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 14:00:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 10:33 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 13:26:41 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Why not keep the
On Friday, 2 May 2014 at 17:34:49 UTC, deadalnix wrote:
framework_structname_function()
You are only proving that you are missing the point completely.
Then I ask you to be graceful and explain it to me.
On Fri, 02 May 2014 14:42:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 11:07 AM, Steven Schveighoffer wrote:
What is the problem with keeping the bits together?
More implementation (I have a BitVector type but not a KBitsVector!k
type), and scanning
On 5/2/14, 11:50 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 14:42:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 11:07 AM, Steven Schveighoffer wrote:
What is the problem with keeping the bits together?
More implementation (I have a BitVector type
On Friday, 2 May 2014 at 17:46:54 UTC, deadalnix wrote:
On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
To make this more useful, turn it into a requirement. It gets
us deterministic destruction for reference types. Example:
...
isolated tmp = new Tempfile();
//
On 5/2/14, 11:56 AM, Andrei Alexandrescu wrote:
If speed is no issue, sure :o). My intuition is that the TwoBitVector
would need certain primitives from BitVector to work well.
Heh, however it's implemented, TwoBitVector's very name implies that
it's cheap to use ;)
On Fri, 02 May 2014 14:56:00 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 11:50 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 14:42:52 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 5/2/14, 11:07 AM, Steven Schveighoffer wrote:
On Fri, 02 May 2014 15:06:13 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
Can you explain to people who don't understand DMD code, does this
exactly
implement the DIP?
Yes.
The two questions above imply that the DIP isn't
On 5/2/2014 6:53 AM, Steven Schveighoffer wrote:
Can you explain to people who don't understand DMD code, does this exactly
implement the DIP?
Yes.
The two questions above imply that the DIP isn't enough to
answer those questions...
It follows the scoping and name resolution rules used for
On Friday, 2 May 2014 at 18:32:13 UTC, Dylan Knutson wrote:
Correct me if I'm wrong here, but this seems really similar to
how Rust does owned pointers and move semantics. Or is there a
large conceptual difference between the two that I'm missing?
I believe that the issues that people are
On Friday, 2 May 2014 at 18:32:13 UTC, Dylan Knutson wrote:
Correct me if I'm wrong here, but this seems really similar to
how Rust does owned pointers and move semantics. Or is there a
large conceptual difference between the two that I'm missing?
Yes, there are some parallels, although
On 5/2/2014 12:21 PM, Jonathan M Davis via Digitalmars-d wrote:
As far as the compiler is concerned, everything
should be either an error or nothing (and Walter agrees with me on this;
It would be nice if all code *could* be considered either good or
error without causing problems. But we
On 4/30/2014 4:17 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
(*) Are we allowed to have gotos any more since Dijkstra's letter?
You better ask the dining philosophers.
Nah, they're too busy trying to
On Friday, 2 May 2014 at 18:10:42 UTC, deadalnix wrote:
On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
That's true, but it is also a breaking change, because then
suddenly some variables aren't writable anymore (or
s/writable/readable/ of course
alternatively, the compiler would
On Friday, 2 May 2014 at 16:20:47 UTC, Andrei Alexandrescu wrote:
On 5/2/14, 9:04 AM, fra wrote:
On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei
Alexandrescu wrote:
I think there's no need to argue that in this community. The
GC never
guarantees calling destructors even today, so this
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
So now it looks like dynamic arrays also can't contain structs
with destructors :o). -- Andrei
Well, that's always been the case, and even worst, since in a
dynamic array, destructor are guaranteed to *never* be run.
On Friday, 2 May 2014 at 19:54:43 UTC, Nick Sabalausky wrote:
Warnings ARE a built-in lint-like tool. On top of that, lint
itself proves that lint tends to not get used. If it's too hard
for people to occasionally toss in a -m32 to check if that
works, then no lint-like tool is going to solve
On Fri, May 02, 2014 at 09:03:15PM +, monarch_dodra via Digitalmars-d wrote:
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
So now it looks like dynamic arrays also can't contain structs with
destructors :o). -- Andrei
Well, that's always been the case, and even worst,
On Fri, 02 May 2014 15:54:37 -0400
Nick Sabalausky via Digitalmars-d digitalmars-d@puremagic.com wrote:
Warnings ARE a built-in lint-like tool.
Perhaps, but having them in the compiler is inherently flawed, because
you have little-to-no control over what it warns about, and you're
forced to
On Fri, 02 May 2014 21:03:15 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
So now it looks like dynamic arrays also can't contain structs
with destructors :o). -- Andrei
Well, that's always been
On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via
Digitalmars-d wrote:
True, that is a problem. But if folks really want the warnings,
they can go to the extra effort.
Why are we making people go to extra effort to get lint-like
functionality if we want it to be something that
Is this in Bugzilla?
On Fri, May 02, 2014 at 11:44:47PM +0200, Jonathan M Davis via Digitalmars-d
wrote:
On Fri, 02 May 2014 21:03:15 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
So now it looks like dynamic arrays
On Friday, 2 May 2014 at 18:32:13 UTC, Dylan Knutson wrote:
Correct me if I'm wrong here, but this seems really similar to
how Rust does owned pointers and move semantics. Or is there a
large conceptual difference between the two that I'm missing?
There is some similarity, but Rust system
On Friday, 2 May 2014 at 20:10:04 UTC, Marc Schütz wrote:
On Friday, 2 May 2014 at 18:10:42 UTC, deadalnix wrote:
On Friday, 2 May 2014 at 09:41:48 UTC, Marc Schütz wrote:
That's true, but it is also a breaking change, because then
suddenly some variables aren't writable anymore (or
We are all sick and tired of this debate, but today I've seen a
question in Stack Exchange's Programmers board that raises a
point I don't recall being discussed here:
Idan Arye:
today I've seen a question in Stack Exchange's Programmers
board that raises a point I don't recall being discussed here:
This program:
class A {
immutable int x;
this() {
foo();
x = 1;
x = 2;
}
void foo() {
auto y = x;
}
}
void
On Friday, 2 May 2014 at 20:59:46 UTC, monarch_dodra wrote:
Yeah, you have to read the fine print: collection implies
destruction *but* no guarantees the collection will actually
ever happen.
That sound like the right balance.
Also, make construction of object with destructor @system as
On Fri, 02 May 2014 22:39:12 +
Meta via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via
Digitalmars-d wrote:
True, that is a problem. But if folks really want the warnings,
they can go to the extra effort.
Why are we making
On Sat, 03 May 2014 00:50:14 +
Idan Arye via Digitalmars-d digitalmars-d@puremagic.com wrote:
We are all sick and tired of this debate, but today I've seen a
question in Stack Exchange's Programmers board that raises a
point I don't recall being discussed here:
On Saturday, 3 May 2014 at 01:17:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The problem that some of what gets warned about is _not_
actually a problem.
If it always were, it would be an error. So, unless you have
control over
exactly what gets warned about and have the ability to
I forgot to add these comments by walter at the top of my
previous post:
[walter Bright wrote ] the thing is, GC is a terrible and
unreliable method of managing non-memory
resource lifetimes. Destructors for GC objects are not guaranteed
to ever run.
So now it looks like dynamic arrays
[ monarch_dodra wrote ] Well, that's always been the case, and
even worst, since in a
dynamic array, destructor are guaranteed to *never* be run.
https://issues.dlang.org/show_bug.cgi?id=2757
Resource Management. A issue that has been discussed since 2009,
and still no *GOOD* solution.
On Thursday, 1 May 2014 at 22:23:22 UTC, Ga wrote:
And I am getting a error LNK2019: unresolved external symbol
GetDeviceCaps referenced in function _Dmain
have you linked gdi32.lib?
On Friday, 2 May 2014 at 06:07:48 UTC, evilrat wrote:
On Thursday, 1 May 2014 at 22:23:22 UTC, Ga wrote:
And I am getting a error LNK2019: unresolved external symbol
GetDeviceCaps referenced in function _Dmain
have you linked gdi32.lib?
Thanks a lot, I wasn't sure what to link with, I
I'm in the process of learning/practicing D and I noticed
something that seems peculiar coming from a C++ background:
If I compile and run:
void fun(const ref int x) {
//Stuff
}
unittest {
fun(5); //Error! Does not compile
}
I get the specified error in my unit test. I understand that
class MyClass {
Appender!string _stringBuilder;
this() {
_stringBuilder = Appender!string(null);
_stringBuilder.clear();
}
@property string str() {
return _stringBuilder.data;
}
void append(string
On 5/2/14, ref2401 via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
class MyClass {
Appender!string _stringBuilder;
this() {
_stringBuilder = Appender!string(null);
_stringBuilder.clear();
Ouch, ouch, ouch! What's happening is that the
On Friday, 2 May 2014 at 08:17:09 UTC, Mark Isaacson wrote:
I'm in the process of learning/practicing D and I noticed
something that seems peculiar coming from a C++ background:
If I compile and run:
void fun(const ref int x) {
//Stuff
}
unittest {
fun(5); //Error! Does not compile
}
I
On Friday, 2 May 2014 at 10:23:03 UTC, Andrej Mitrovic via
Digitalmars-d-learn wrote:
Ouch, ouch, ouch! What's happening is that the 'clear' Appender
method
is only compiled-in if the data is mutable, otherwise you end up
calling the object.clear UFCS function. So don't use clear here.
I don't
1 - 100 of 166 matches
Mail list logo
