Uh... destructors?

[%u]

>> Because a pure unsafe function is useless.

> I disagree. Suppose you have a function which is conceptually pure but requires a temporary 100
Mb matrix of doubles. Wouldn't it make sense to use malloc/free for this temporary storage
instead of using the GC and risking the block never being collected because of a false pointer
somewhere?

This is _precisely_ why I think the 'delete' keyword will still have uses -- it lets you delete
memory that you _know_ will no longer be needed, and it gets read if the need to malloc/free. As
a bonus, it will be much less "special" of a case than excepting the ordinary malloc/free
functions.
But anyway, I doubt that that's going to convince anyone, so I'll stop talking about the delete
keyword. :)

Another point is that the problem with false pointers is actually an implementation flaw in the D
runtime, _not_ an issue with the language. I actually think that even an extremely small chance
at remote possibility of a false pointer will provide enough reason for people to avoid adopting
D, notwithstanding the greatness (IMHO) of the language as it currently is. If D is going to be
adopted on a large scale, I don't think it's going to happen with the possibility of false
pointers looming in the dark.
It would be an architectural change for the GC (and probably the compiler) to fix the issue, but
now that it's brought up, I think it might be a good idea to revisit it, since even if it's not a
great possibility, it's obviously an uneasiness lurking in the back of people's heads, and a
hindrance to the adoption of the language.
Any thoughts on this? (Should this GC discussion be a separate thread?)