>> 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?)
