A few general thoughts

[Francisco Almeida]

On 29-04-2011 10:30, lenochware wrote:
> This post is in fact mainly about removing delete, but I didn't wont make
> everyone angry just with title.:) I am sure not expert to language design, so
> I should probably be quiet, but I have question.
> My question is: Didn't break it (i.e. removing delete) compatibility?

This has been acknowledged. Yes, removing delete in D2 will break 
compatibility with existing code. However, I'm sure that at an early 
stage, the compiler will probably issue error messages once it 
encounters delete statements, for which the fix is quite easy: just 
remove them, and recompile. As an unfortunate side effect, a few other 
problems might occur, especially for shared objects. But refactoring to 
a simpler system, in which the garbage collector is trusted to manage 
the heap, should be easy.

Keep in mind though, most manual memory management done in D was done 
using D1, which will *not* have its delete operator removed. Only D2 
will see the change.

> In my opinion every decision have both bad and good sides, which should be
> carefully weighted. (I hope that you can understand me, because english is not
> my native language)

I too had a lot of concern (and was pretty vocal about it), but there 
are few misconceptions people often have:

- The removal of delete does *not* prevent one from doing manual memory 
management. malloc/free are available, as well as the emplace() function 
that allows to declare class objects on the C heap.

- The removal of delete does *not* remove RAII from the language. There 
is now an important semantical separation between struct and class: 
structs are declared on the stack by default, are scoped, and can use 
the traditional scheme of being initialized in the constructor and 
terminated in the destructor. Classes are garbage collected by default.

> For me, backward compatibility is important issue. I am sure that this topic
> was discussed here many times, but I want just say that I vote for more
> careful way to make changes in language. It is even more important for young
> language, I believe, because many libraries and tools can stay incompatible
> for long time. For example I am not using D2.0, because I have incompatible
> libraries in my project and it seems it cannot be fixed easy way.
> What about mark features to remove as "deprecated" and write warning by
> compiler, if they are used? So feature would be really removed after some time
> in next version, and people would be informed this way and have time to
> prepare your code or discuss change.

If you are still using D1, do not worry. D1 code should unaffected by 
the change.

> I am not against breaking compatibility entirely, but it should be compensated
> with really significant improvement.

There are enough improvements in my opinion. :)

> Another thing with bad and good sides is "dangerous" feature, as was mentioned
> for delete. In my opinion more safety means often more restrictive language
> (and now I am speaking in general, not about
> "delete"). For example C gives you big freedom, but it is very dangerous.
> Modern languages are much more restrictive. But sometimes I prefer dangerous
> feature (if it is not "too dangerous"), which give me more freedom. Because
> even smartest language designer cannot see all real situations possible and
> restriction which cannot be disabled can be very annoying.

This is a discussion I can still go into ocasionally. The philosophy of 
"making what is best easier and what is wrong harder" can lead to 
undesired consequences. Who is to decide what approach is "right" or 
"wrong" for each problem?

With delete, I have reached the conclusion that this is not the case 
however. The options for memory management are still kept open, and the 
best we can do is hope that the GC is improved in the near future.