David Simcha's stats library is full of useful code and it was a
shame to let it rot. I've patched it up to work with modern D
compilers and added dub support.
https://github.com/John-Colvin/dstats
http://code.dlang.org/packages/dstats
I have also made a pull request to David's repository to
I wish I'd asked for the mic before I made the (inaudible)
comment about signedness, so here it is:
Subtracting unsigneds is almost always a bug. The problem
(realised by the C++ community) is that length should be signed.
Atila
On Wednesday, 16 July 2014 at 16:51:19 UTC, Andrei
http://www.reddit.com/r/programming/comments/2ayt42/dconf_2014_adam_d_ruppes_amazing_slideless_talk/
https://www.facebook.com/dlang.org/posts/886573308023018
https://twitter.com/D_Programming/status/489811286897983489
Andrei
BTW here's the post Andrei made on the day of with the little
notebook paper I used for a topic list and some discussion we had
in May:
http://forum.dlang.org/thread/llo7i8$e4e$1...@digitalmars.com
Also, my book is out now, it was published the Monday after the
talk!
Here's the link:
http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book
On Thursday, 17 July 2014 at 16:39:28 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/2ayt42/dconf_2014_adam_d_ruppes_amazing_slideless_talk/
https://www.facebook.com/dlang.org/posts/886573308023018
https://twitter.com/D_Programming/status/489811286897983489
On 7/17/14, 10:43 AM, Adam D. Ruppe wrote:
Also, my book is out now, it was published the Monday after the talk!
Here's the link:
http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book
Put that on reddit. -- Andrei
On Thursday, 17 July 2014 at 18:37:54 UTC, Andrei Alexandrescu
wrote:
Put that on reddit. -- Andrei
I've tried a few times and it doesn't work.. the post appears to
me, but is invisible to everyone else. I think reddit's silent
spam filter dislikes the link.
I can tell them to search the
On Thursday, 17 July 2014 at 18:42:38 UTC, Adam D. Ruppe wrote:
On Thursday, 17 July 2014 at 18:37:54 UTC, Andrei Alexandrescu
wrote:
Put that on reddit. -- Andrei
I've tried a few times and it doesn't work.. the post appears
to me, but is invisible to everyone else. I think reddit's
silent
On Thursday, 17 July 2014 at 18:48:11 UTC, deadalnix wrote:
You may have been shadow banned. You should contact some reddit
admins.
It doesn't seem to be my account itself, just that link. Someone
else says they tried posting it too but I can't see it, I think
reddit just doesn't like the
On 7/17/2014 12:29 PM, Adam D. Ruppe wrote:
On Thursday, 17 July 2014 at 18:48:11 UTC, deadalnix wrote:
You may have been shadow banned. You should contact some reddit admins.
It doesn't seem to be my account itself, just that link. Someone else says they
tried posting it too but I can't see
On Tuesday, 15 July 2014 at 19:00:35 UTC, Walter Bright wrote:
On 7/15/2014 11:28 AM, John wrote:
At the end of this video, it sounds like it ends abruptly..
While answering a question, Walter says.. 'it turns out..' and
the video ends
there.
That's when my time ran out and I vanished in a
On Thursday, 17 July 2014 at 15:20:20 UTC, John Colvin wrote:
David Simcha's stats library is full of useful code and it was
a shame to let it rot. I've patched it up to work with modern D
compilers and added dub support.
https://github.com/John-Colvin/dstats
On Thu, 17 Jul 2014 20:57:10 +, Kiith-Sa wrote:
I want to eventually try to merge this back to the default repository,
but I'd like some comments/criticism/ideas first. Should any snippets be
removed? Added? Any problems with the current snippets? (the wrap in
try/catch in the previous
On Thursday, 17 July 2014 at 20:57:10 UTC, Kiith-Sa wrote:
DSnips is a set of UltiSnips snippets for D (now with GIFs
showing each snippet in action (image-heavy))
https://github.com/kiith-sa/DSnips
This is an attempt to overhaul the D snippets I got merged to
UltiSnips (now a separate
On 7/16/2014 5:15 AM, Jaroslav Hron wrote:
On Tuesday, 15 July 2014 at 16:20:34 UTC, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/
https://www.facebook.com/dlang.org/posts/885322668148082
On 7/16/2014 7:21 AM, dennis luehring wrote:
can you give an short (working) example code to show the different resulting
assembler for your for-rewrite example - and what compilers your using for
testing - only dmd or gdc?
I used dmd.
Am 18.07.2014 04:52, schrieb Walter Bright:
On 7/16/2014 7:21 AM, dennis luehring wrote:
can you give an short (working) example code to show the different resulting
assembler for your for-rewrite example - and what compilers your using for
testing - only dmd or gdc?
I used dmd.
i
On 7/17/2014 9:40 PM, dennis luehring wrote:
i understand your focus on dmd - but talking about fast code and optimizing
WITHOUT even trying to compare with other compiler results is just a little bit
strange for someone who stated speed = money
The point was to get people to look at the asm
On 7/16/2014 1:12 PM, Johannes Pfau wrote:
I'll take this as you pre-approve all the mentioned extensions?
* way to disable typeinfo for struct
Worth investigating. It'd probably be much more effective to work the linker
angle of removing items for which no references exist. Martin was
On 7/16/2014 3:42 PM, Trass3r wrote:
The implementation doesn't seem to be correct.
Could anybody versed in this look into it?
version(Windows)
{
private extern __gshared fenv_t _FE_DFL_ENV;
fenv_t* FE_DFL_ENV = _FE_DFL_ENV;
}
There's no such symbol in the libcmt and it fails to
On 17 July 2014 07:09, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/16/2014 1:12 PM, Johannes Pfau wrote:
I'll take this as you pre-approve all the mentioned extensions?
* way to disable typeinfo for struct
Worth investigating. It'd probably be much more
On Wednesday, 16 July 2014 at 20:11:22 UTC, Johannes Pfau wrote:
I think it's kinda ridiculous that D embedded code will only be
usable
with strong optimization flags, but whatever.
Do you have numbers? Transitive volatility implies you planned to
do very complex things in embedded. If
On Wednesday, 16 July 2014 at 20:14:38 UTC, Johannes Pfau wrote:
* way to disable typeinfo for struct
* way to disable initializer
* force inlining
* (way to omit copy constructor function / force inline)
BTW, can't lto already remove this unused data? LDC inlines
simple initializers already,
Walter Bright:
Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the
situation.
Bye,
bearophile
On Wednesday, 16 July 2014 at 21:26:41 UTC, Gary Willoughby wrote:
This was asked a few years ago and i could find a definitive
answer.
http://forum.dlang.org/thread/jo2c0a$31hh$1...@digitalmars.com
On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen
wrote:
I don't think the
On Wednesday, 16 July 2014 at 21:02:42 UTC, Timon Gehr wrote:
On 07/16/2014 01:22 PM, Remo wrote:
On Monday, 14 July 2014 at 23:43:57 UTC, H. S. Teoh via
Digitalmars-d
wrote:
On Mon, Jul 14, 2014 at 11:22:53PM +, John Carter via
Digitalmars-d wrote:
[...]
Any other good blog posts /
On 7/17/2014 1:28 AM, bearophile wrote:
Walter Bright:
Unless a convincing counter argument emerges, yes.
Please Walter, list your convincing arguments to not fix the situation.
Breaks existing, working code for little gain. I suggested a fix that deals with
the issue and does not break
Deprecation of LastCatch doesn't break existing code either.
It appears still to be a general meme that performance required no GC
and GC mean poor performance. The debate has been restarted on the Go
mailing list under the banner go without garbage collector. The
response to will Go remove the garbage collector was somewhat
unequivocal: nope.
--
Russel.
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required
no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list under the banner go without garbage collector.
The
On Thursday, 17 July 2014 at 08:56:40 UTC, Chris wrote:
The funny thing about C++ is that there is a plethora of books
that teach you how to do it right, which is a sign that there
is something inherently wrong with the language*. I find that
in D there aren't many ways to *really* do it
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance
required no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list
On 7/17/2014 2:40 AM, bearophile wrote:
Walter Bright:
Breaks existing, working code for little gain. I suggested a fix that deals
with the issue and does not break existing code.
This is not yet convincing. Let's talk about the Pokemon Exception Handling,
for when you just Gotta Catch 'Em
H. S. Teoh via Digitalmars-d wrote in message
news:mailman.4230.1405534833.2907.digitalmar...@puremagic.com...
But maybe some of the DMD experts can speak up about this. ;-)
This is fairly well known, the same thing exists for static variables and
nested functions etc. I think there is
Walter Bright:
Breaks existing, working code for little gain. I suggested a
fix that deals with the issue and does not break existing code.
This is not yet convincing. Let's talk about the Pokemon
Exception Handling, for when you just Gotta Catch 'Em All :-) I
think the D/Python code that
On Thursday, 17 July 2014 at 09:32:15 UTC, Chris wrote:
On Thursday, 17 July 2014 at 08:56:40 UTC, Chris wrote:
The funny thing about C++ is that there is a plethora of books
that teach you how to do it right, which is a sign that there
is something inherently wrong with the language*. I
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
That's good news in a way. If a big company accepts GC and the
Go crowd go with it (pardon the pun), then it will find more
acceptance (as Paulo pointed
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
I.e. it's why, not why not make a breaking change.
Especially since it is apparently a commonly used coding
pattern, appearing 25 times in Phobos alone.
What?
The plan is to keep the syntax that is used in Phobos and get rid
of
On Thu, 2014-07-17 at 09:32 +, Chris via Digitalmars-d wrote:
[…]
Also, if the trend in C++ is to go back to functional programming
(don't use classes, inheritance etc.), then what's the point? Why
not use C instead. It's kinda absurd.
C cannot do RAII, nor can it do internal DSL (via
Slight correction : it is not a mangling of variable that is a
problem (local variables don't have any mangling) but mangling of
the function itself (it naively uses variable name for mangled
name generation). Should use something like unique id instead.
On Thursday, 17 July 2014 at 09:57:37 UTC, Walter Bright wrote:
I.e. it's why, not why not make a breaking change.
Especially since it is apparently a commonly used coding
pattern, appearing 25 times in Phobos alone.
It is used 0 times in Phobos. In fact I have not seen it used for
a single
currysoup wrote in message news:iustbzgyagrlbtnfc...@forum.dlang.org...
Once you're going to
these lengths to avoid garbage collection it begs the question,
why are you even using this language?
Because D has plenty of other things to offer.
Dicebot wrote in message news:dikroykmroruujndl...@forum.dlang.org...
It is used 0 times in Phobos. In fact I have not seen it used for a single
time in any living project - guess because any sane person understands how
terrible of a misfeature it is.
I've used it, because I'm lazy.
On Thursday, 17 July 2014 at 10:38:46 UTC, Daniel Murphy wrote:
You will break some code if you disallow it.
An alternative was presented here: a warning and deprecation.
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance
required no GC
and GC mean poor
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme
On Thursday, 17 July 2014 at 09:52:45 UTC, eles wrote:
On Thursday, 17 July 2014 at 09:32:15 UTC, Chris wrote:
On Thursday, 17 July 2014 at 08:56:40 UTC, Chris wrote:
The funny thing about C++ is that there is a plethora of
books that teach you how to do it right, which is a sign that
there
On Thursday, 17 July 2014 at 11:20:30 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:52:45 UTC, eles wrote:
On Thursday, 17 July 2014 at 09:32:15 UTC, Chris wrote:
On Thursday, 17 July 2014 at 08:56:40 UTC, Chris wrote:
Then why not create C+++ that keeps these useful features and
get
On Thursday, 17 July 2014 at 11:29:40 UTC, eles wrote:
On Thursday, 17 July 2014 at 11:20:30 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:52:45 UTC, eles wrote:
On Thursday, 17 July 2014 at 09:32:15 UTC, Chris wrote:
On Thursday, 17 July 2014 at 08:56:40 UTC, Chris wrote:
Then why not
On Thursday, 17 July 2014 at 11:48:20 UTC, Chris wrote:
On Thursday, 17 July 2014 at 11:29:40 UTC, eles wrote:
On Thursday, 17 July 2014 at 11:20:30 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:52:45 UTC, eles wrote:
On Thursday, 17 July 2014 at 09:32:15 UTC, Chris wrote:
On Thursday,
On Thursday, 17 July 2014 at 08:50:12 UTC, John Colvin wrote:
Every machine D will feasibly support will do T.max + 1 ==
T.min and T.min - 1 == T.max for native integral operations,
signed or unsigned.
In fact, the spec mandates this (see AddExpression): If both
operands are of integral
On 16/07/14 11:56, Vic wrote:
Java is the devil I know.
But if D is not my first choice to port(from Java), than my second
choice is Qt.
There is DWT [1], which is a port of the Java library SWT.
[1] https://github.com/d-widget-toolkit/dwt
--
/Jacob Carlborg
On Thursday, 17 July 2014 at 10:03:08 UTC, Daniel Murphy wrote:
The solution is also fairly straightforward - give each local
declaration a unique name (for mangling only). It probably
requires some minor structural changes in dmd.
As an aside, these names should be independent of
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme
The key to making D's GC acceptable lies in two factors I believe.
1. Improve the implementation enough so that you will only be
impacted by GC in extermely low memory or real time environments.
2. Defer allocation more and more by using ranges and algorithms
more, and trust that compiler
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required
no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list under the banner go without garbage collector.
The
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just from watching a few of the DConf 2014 talks, if you want
performance you avoid the GC at all costs (even if that means
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
Don't know if it's really a major concern or the favorite
weak spot that C++ et. al guys like to flog to death in order
to distract from the many strengths that D has (in comparison
with C++ et al.) The answer is always D has GC, it's
I opened a number of bugs regarding ambiguities while writing
core.demangle. They're all tagged with some searchable keyword
too, though I can't recall what it is.
On Thursday, 17 July 2014 at 13:30:15 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
*According to Don Clugston's talk the default GC can pause for
~250ms which is totally insane for any kind of interactive or
near-real-time system. If their concurrent version
On Wed, 16 Jul 2014 11:49:21 -0700, Walter Bright wrote:
I'll add that if it turns out we can't do a wrapper because of some
limitations/bugs in D's expressiveness, that is the problem with D we
need to fix, not adding another type modifier.
It all comes down to leverage. Making user
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
If D came without GC, it would have replaced C++ a long time
ago!
That's overly optimistic I think, but I believe that the adoption
rate would have been far greater for a D without GC, or perhaps
with a more GC friendly design, as the GC
Iain Buclaw via Digitalmars-d wrote in message
news:mailman.4214.1405521071.2907.digitalmar...@puremagic.com...
No they don't. Intrinsics make things worse.
? At worst they're useless.
They are _trivial_ to implement for any of the compilers.
No they aren't, unless you are talking
Seems that I saw similar post but about plain arrays somewhere
but currently I can't find it. The topic is that when I
initialize associative array of interfaces with AA-literal
consisting of derived class objects I get compiler error.
import std.stdio;
interface IBase
{
}
class
I feel it is a major concern, if I'm starting a project with
low latency requirements* I certainly think twice about using
D. I think this could apply especially to people outside the
community who might not have experienced the benefits D
provides. The issue is not there is a GC, it's that
On Wednesday, 16 July 2014 at 17:47:09 UTC, Nick Sabalausky wrote:
On 7/15/2014 3:56 PM, Robert burner Schadek wrote:
On Tuesday, 15 July 2014 at 18:28:14 UTC, Walter Bright wrote:
Even more amazing, Germans all have D plastered on their
cars!
So we don't forget were we are :D
That's
On Thursday, 17 July 2014 at 08:50:12 UTC, John Colvin wrote:
there may be ways of telling backends that it is defined and we may be using
those ways, I don't know.
For GDC, it's the '-fwrapv' switch, but it's not enabled by default for D.
artur
On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
If D came without GC, it would have replaced C++ a long time
ago!
That's overly optimistic I think, but I believe that the
adoption rate would have been far greater for a D
Artur Skawina:
For GDC, it's the '-fwrapv' switch, but it's not enabled by
default for D.
I think it has to be enabled by default, plus you can add a
switch to disable that standard D semantics.
Bye,
bearophile
Actualy I found this bug report, but I don't know if there
suggested something around associative arrays
https://issues.dlang.org/show_bug.cgi?id=5498
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just from watching a few of the DConf 2014 talks, if you want
On Thursday, 17 July 2014 at 15:19:59 UTC, bachmeier wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just
Araq rump...@web.de wrote:
The paper focusses on RC vs tracing. My point is tracing vs copying
is another tradeoff. Here is a marksweep algorithm:
- Trace live objects.
- For each dead object: Deallocate.
Here is a copying GC:
- Trace and copy live objects.
- There is no deallocation
Uranuz:
Actualy I found this bug report, but I don't know if there
suggested something around associative arrays
https://issues.dlang.org/show_bug.cgi?id=5498
I think it's a bug. Issue 5498 it's better left closed. Search if
another more specific bug is open on this, or open a new one
On 7/15/14, 9:25 AM, Johannes Pfau wrote:
DIP62 describes how to solve this problem and make embedded programming
a first-class citizen in D:
http://wiki.dlang.org/DIP62
[snip]
The good:
This is a very crisply-written and comprehensive proposal. It could use
a little work (e.g. define the
On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu
wrote:
I think an approach based on functions peek/poke is a lot more
promising. D programs must define sequences of std calls
anyway, otherwise even the simplest programs that use
writeln(What's your name?) followed by a readln()
We had the volatile statement as a compiler barrier in D1. Why
not basically that instead of a type qualifier? We pretty much
need it back for atomics anyway.
On 7/17/14, 2:57 AM, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required no GC
and GC mean poor performance. The debate has
On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
For improving the GC to an acceptable level, I believe
collection only needs to execute fast enough such that it will
fit within a frame comfortably. So for something rendering at
60FPS you have 1 second / 60 frames ~= 16.6 milliseconds
Just watched Don's DConf 2014 talk where he said D has to be
ruthless about
memory inefficiency. Here's one thing that I think could help
avoid unnecessary garbage: built-in syntax for this:
import core.stdc.stdlib : alloca;
ubyte[] buffer = (cast(ubyte*) alloca(bufsize)) [0 .. bufsize];
Tero:
Allocating in the stack seems ideal so I'd encourage that by a
clean syntax. I keep missing
this feature.
See:
https://issues.dlang.org/show_bug.cgi?id=9832
http://en.cppreference.com/w/cpp/container/dynarray
Bye,
bearophile
On Thursday, 17 July 2014 at 16:28:00 UTC, Tero wrote:
Just watched Don's DConf 2014 talk where he said D has to be
ruthless about
memory inefficiency. Here's one thing that I think could help
avoid unnecessary garbage: built-in syntax for this:
import core.stdc.stdlib : alloca;
ubyte[]
Kapps:
In theory there would probably be an allocator that uses alloca
when Andrei's std.allocator makes it in.
How is it going to work?
Also, there used to be a built in syntax, 'scope foo = new
Foo()' that would allocate on the stack, but that's deprecated
now
Perhaps once the scope
Reduced:
interface IBase {}
class Impl(T): IBase {
T value;
}
void main() {
IBase a = true ? (new Impl!uint) : (new Impl!string);
}
test.d(6,23): Error: cannot implicitly convert expression (new
Impl!uint) of type object.Object to test.IBase
Bye,
bearophile
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
snip
If D came without GC, it would have replaced C++ a long time
ago!
Agree +1000.
If GC is so good, why not make it an option, have a base lib w/o
GC.
If I want GC, I got me JRE. It seems that some in D want to write
a better JRE,
On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
snip
GC phobia is a convenient excuse for people to not use D,
people who may have different actual reasons that they don't
express for various reasons or may not even realize.
Hi Walter,
Please give us a bit more respect and
Hi,
I'm trying to update std.typecons.Unique. I want to add a static opCall
with no arguments to simulate a nullary-argument constructor.
Unfortunately, with a recent dmd from Git, I get this (reduced code):
class Class {}
struct U
{
Class c;
this(A...)(A args)
if (A.length !=
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib
w/o GC.
Much of Phobos already is GC free. The parts that aren't should
be easy to convert to use user-supplied buffers. Please add
enhancement requests for cases where there
interface IBase {}
class Impl(T): IBase {
T value;
}
void main() {
IBase a = true ? (new Impl!uint) : (new Impl!string);
}
I have added a note:
https://issues.dlang.org/show_bug.cgi?id=3543
Bye,
bearophile
On Thursday, 17 July 2014 at 17:15:54 UTC, bearophile wrote:
interface IBase {}
class Impl(T): IBase {
T value;
}
void main() {
IBase a = true ? (new Impl!uint) : (new Impl!string);
}
I have added a note:
https://issues.dlang.org/show_bug.cgi?id=3543
Bye,
bearophile
OK. Thanks. Using
Uranuz:
OK. Thanks. Using casts everywhere for such case us quite
annoying. I've tested it for plain array it doesn't work too.
However issue is marked as solved for it.
It's not exactly the same issue. Issue 3543 seems more fitting.
In D interfaces and classes are not the same thing.
Vic:
If D came without GC, it would have replaced C++ a long time
ago!
Agree +1000.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib
w/o GC.
Much of Phobos already is GC free. The parts that aren't should
be easy to convert to use user-supplied
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
Vic wrote in message news:xblbppsybigjgrtgi...@forum.dlang.org...
Hi Walter,
Please give us a bit more respect and benefit of the doubt and assume that
we do know what we want when say something.
I want to use D! I may be forced to C++ my team because GC built into the
base lib. It is
On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
snip
The quality of GC implementation is probably more important.
I disagree, I am a burn victim and don't trust smoke.
Ideally it is optional.
Cheers,
Vic
On Thu, Jul 17, 2014 at 05:32:36PM +, Right via Digitalmars-d wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
[...]
I don't, so here. :D
T
--
I see that you JS got Bach.
On 17/07/2014 18:11, Nick Treleaven wrote:
opcall.d(24): Error: struct opcall.U static opCall is hidden by
constructors and can never be called
opcall.d(24):Please use a factory method instead, or replace all
constructors with static opCall.
I should mention that std.typecons.Unique
On Thu, Jul 17, 2014 at 05:28:01PM +, Vic via Digitalmars-d wrote:
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib w/o GC.
Much of Phobos already is GC
1 - 100 of 299 matches
Mail list logo
