On Tuesday, 30 May 2017 at 10:30:13 UTC, qznc wrote:
Currently, a good answer is to direct people to the "Don't fear
the reaper" [0] article, but I feel it does not really address
all concerns of people. Concerns like:
That was the introductory post in what I hope will be a long
series where
On Sunday, 28 May 2017 at 18:50:02 UTC, Nerve wrote:
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote:
All in all, I see little to no benefit to what you propose,
while requiring significant work on the language spec.
Point taken. My only remaining reservation then is the
communi
On 05/29/2017 06:25 AM, aberba wrote:
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote:
On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
With regards to your popularity argument: IMHO the only people we
should concern ourselves with are those that evaluate which are the
righ
On Monday, 29 May 2017 at 11:58:56 UTC, evilrat wrote:
Can't sell to those who don't buy.
I can't say for all, but I have noticed that those who
generally use C++ will tell that speed matters "everywhere" (oh
right, they do use C++ "for a reason")
Well, I am in that C++ group... So yes, you c
On Monday, 29 May 2017 at 11:06:20 UTC, Ola Fosheim Grøstad wrote:
One fun tutorial would be to integrate with a tedious C++
framework and let the GC take care of allocations in C++ code
where speed doesn't matter.
Then write a C++ integration tutorial around it.
That could be a selling poi
On Monday, 29 May 2017 at 01:36:31 UTC, Mike Parker wrote:
More broadly, I think what we need to be doing is teaching
people that D's GC is not their grandfather's GC and that,
unless they are doing something highly specialized, they
probably don't need alternatives. The GC is fine by itself fo
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote:
On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
With regards to your popularity argument: IMHO the only people
we should concern ourselves with are those that evaluate which
are the right tools for their current task as objec
On Sunday, 28 May 2017 at 18:50:02 UTC, Nerve wrote:
Point taken. My only remaining reservation then is the
communication problem D has with the wider prospective
programming world in conveying that the GC has alternatives
that work.
More broadly, I think what we need to be doing is teaching
On Sunday, 28 May 2017 at 18:50:02 UTC, Nerve wrote:
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote:
All in all, I see little to no benefit to what you propose,
while requiring significant work on the language spec.
Point taken. My only remaining reservation then is the
communi
On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote:
All in all, I see little to no benefit to what you propose,
while requiring significant work on the language spec.
Point taken. My only remaining reservation then is the
communication problem D has with the wider prospective
progr
On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
--- refcounted ---
The allocation method used by refcounted can be overloaded...
1. Then the deallocation has to also be overloaded.
2. This introduces tight coupling between a type and its
allocator, preventing the programmer from reusi
On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
Thanks to Walter Bright's recent comments at Dconf about memory
safety, and my own lamentations about the continued use of C in
all contexts where memory safety is crucial by overconfident
programmers who believe they can do no wrong, I've de
Thanks to Walter Bright's recent comments at Dconf about memory
safety, and my own lamentations about the continued use of C in
all contexts where memory safety is crucial by overconfident
programmers who believe they can do no wrong, I've decided to
propose a baked-in RAII implementation for D
13 matches
Mail list logo
