January 09, 2012
On Mon, 09 Jan 2012 09:47:13 -0500, Zachary Lund <admin@computerquip.com> wrote:

> On 01/09/2012 07:58 AM, Steven Schveighoffer wrote:
>> On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:
>>
>>> 7. Unstable language. They're currently considering doing things like
>>> removing "delete" as it's apparently deprecated (which will officially
>>> make it not usable as an SP language).
>>> Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP
>>> language... unless you ignore the GC completely, which isn't even
>>> possible, practically speaking.
>>
>> C doesn't have delete.
>>
>> But removing delete isn't the problem anyways. Here is the problem
>> (which exists with delete present in the language):
>>
>> class C
>> {
>> private int[] buf;
>> this() { buf = new int[5]; }
>> ~this() {/* can't destroy buf here */}
>> }
>>
>> void main()
>> {
>> auto c = new C;
>> delete c; // doesn't destroy c.buf
>> }
>>
>> What we need is a way to hook deterministic destruction vs. GC
>> destruction. Only then, a SP language will you be.
>>
>> -Steve
>
> I was under the impression you could overload new and delete per class/union/struct which gave you the ability to control how things were allocated.

Currently, but scheduled for deprecation (to be replaced by existing library solutions).  But it's not good enough anyways.  If I want to use the GC to allocate my buffer, I still must rely on the GC to destroy it, even if I destroy my class deterministically.  Using an allocator won't fix that.

-Steve
January 09, 2012
"note that D removes probably the most important feature of C++ that makes C++ so powerful: templates and replaces it with something even weaker than Java generics"

I had to read that sentence over again. Did he say "D"? Oh well... talking about misperceptions.
January 09, 2012
On 1/9/2012 1:02 AM, Jonathan M Davis wrote:
> I believe that the general idea is that if you want to manually manage memory,
> then you don't use the GC heap, though core.memory.GC will still allow some
> level of manual control for the GC. I'm not aware of any plan to add a
> "delete" function to anything, but if something like that is added, it'll
> probably be to core.memory with the idea that it's there if you really need it
> but that you really shouldn't be using it normally. Explicitly freeing memory
> goes with manually memory management, not garbage collection.
>
> - Jonathan M Davis

The precise trouble with that is that the _language_ DEPENDS on a GC in order to function correctly.

Arrays, AAs, closures, etc. use a GC for allocation, and essentially you're saying "don't delete AAs", even though that could very well be the memory hog in my program.
Object /also/ depends on a GC... yes, we have emplace(), yada yada, but it's is pretty darn un-handy to use (compared to placement new in C++, which is a breeze) so it's indeed quite a bit more difficult to use than in C++.

Unless you're saying I can't use AAs if I don't want a GC, then I don't see how that argument works out.
January 09, 2012
Already possible via Runtime.collectHandler, though I'll admit it could be done more elegantly.

Sent from my iPhone

On Jan 9, 2012, at 5:58 AM, "Steven Schveighoffer" <schveiguy@yahoo.com> wrote:

> On Sun, 08 Jan 2012 18:28:54 -0500, Mehrdad <wfunction@hotmail.com> wrote:
> 
>> 7. Unstable language. They're currently considering doing things like removing "delete" as it's apparently deprecated (which will officially make it not usable as an SP language).
>>    Looks 100% correct. Removing 'delete' /does/ make D unusable as an SP language... unless you ignore the GC completely, which isn't even possible, practically speaking.
> 
> C doesn't have delete.
> 
> But removing delete isn't the problem anyways.  Here is the problem (which exists with delete present in the language):
> 
> class C
> {
>   private int[] buf;
>   this() { buf = new int[5]; }
>   ~this() {/* can't destroy buf here */}
> }
> 
> void main()
> {
>   auto c = new C;
>   delete c; // doesn't destroy c.buf
> }
> 
> What we need is a way to hook deterministic destruction vs. GC destruction.  Only then, a SP language will you be.
> 
> -Steve
January 09, 2012
On 1/9/2012 7:31 AM, Marco Leise wrote:
> "note that D removes probably the most important feature of C++ that makes C++
> so powerful: templates and replaces it with something even weaker than Java
> generics"
>
> I had to read that sentence over again. Did he say "D"? Oh well... talking about
> misperceptions.

Also, he talks about D debuting in 1999. At the end of 1999, I decided to start working on it. A working compiler didn't appear until 2003 or so, though that was very primitive compared with what we have now.
January 09, 2012
On Monday, January 09, 2012 10:15:37 Walter Bright wrote:
> On 1/9/2012 7:31 AM, Marco Leise wrote:
> > "note that D removes probably the most important feature of C++ that makes C++ so powerful: templates and replaces it with something even weaker than Java generics"
> > 
> > I had to read that sentence over again. Did he say "D"? Oh well... talking about misperceptions.
> 
> Also, he talks about D debuting in 1999. At the end of 1999, I decided to start working on it. A working compiler didn't appear until 2003 or so, though that was very primitive compared with what we have now.

I suspect that part of the problem is that Wikipedia lists D as appearing in 1999. And, of course, since D2 didn't start until 2007, saying that D has been around since 1999 easily gives the mistaken impression that we're doing a bad job, since D _still_ isn't complete and fully stable.

- Jonathan M Davis
January 09, 2012
On 1/9/2012 10:59 AM, Jonathan M Davis wrote:
> I suspect that part of the problem is that Wikipedia lists D as appearing in
> 1999. And, of course, since D2 didn't start until 2007, saying that D has been
> around since 1999 easily gives the mistaken impression that we're doing a bad
> job, since D _still_ isn't complete and fully stable.

Please fix the wikipedia entry!
January 09, 2012
On Monday, January 09, 2012 11:37:50 Walter Bright wrote:
> On 1/9/2012 10:59 AM, Jonathan M Davis wrote:
> > I suspect that part of the problem is that Wikipedia lists D as appearing in 1999. And, of course, since D2 didn't start until 2007, saying that D has been around since 1999 easily gives the mistaken impression that we're doing a bad job, since D _still_ isn't complete and fully stable.
> 
> Please fix the wikipedia entry!

With what? Make it say 2003 for D1 and 2007 for D2?

- Jonathan M Davis
January 09, 2012
On Mon, 09 Jan 2012 14:37:50 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/9/2012 10:59 AM, Jonathan M Davis wrote:
>> I suspect that part of the problem is that Wikipedia lists D as appearing in
>> 1999. And, of course, since D2 didn't start until 2007, saying that D has been
>> around since 1999 easily gives the mistaken impression that we're doing a bad
>> job, since D _still_ isn't complete and fully stable.
>
> Please fix the wikipedia entry!

According to the D changelog, the first version was released in 2001.

-Steve
January 09, 2012
Jonathan M Davis wrote:
> easily gives the mistaken impression that we're doing a bad job

... but only for easy people.

In addition:

a:without indication of paid time there isn't a "job";
b:without specifying the number of full-time service providers, there
isn't a "we"

-manfred