deprecated delete and manual memory management

[Ulrik Mikaelsson]

2011/4/26 Timon Gehr <timon.gehr at gmx.ch>:
> But you understand why it is deprecated for GC memory?
>
> The main thing to note is that the semantics of C++ 'new' and D 'new' are rather
> different.
> D 'new' performs allocation on the GC heap by default. The only sane overloads of
> 'new' would therefore allocate the object on a custom GC heap, which you never
> want to do. So there is absolutely no way to overload the 'new' operator
> meaningfully inside the D language. The argument for removing 'delete' overloading
> is trivial after taking that into consideration.
>
> You can still create custom allocators by the means of template functions. (I do
> not think this is optimal though because they duplicate code that needn't be) They
> feel a little bit less natural though, which is not a problem, since in D, custom
> allocators and manual memory management in general, _are_ less natural.

One thing that is perhaps obvious, but eludes me; when dropping the
delete-operator, are there any obvious reason to not also drop the
"new" keyword? ("new" is a fairly good method/variable name, if
nothing else)

I could see two possible alternatives:

Global (and defined-by-default) template new!(Type): (as suggested
elsewhere in this thread by so)
  This is very close to the current situation, but makes it possible
to use as a method-name, and clearly states there's nothing "magic"
about it.

Explicit Allocator, such as GC.new!(Type).
  Would have the benefit of clearly showing who did the allocation,
and would map nicely to other allocators. (Malloc.new/free!(T)!(T)).

  It would also allow library-methods that might allocate instances,
take an allocator as an optional template argument. I.E.
    auto obj = dict.createObject("key");
  OR
    auto obj = dict.createObject!(Malloc)("key");
    scope(exit) Malloc.free(obj);

Possibly an obvious bad idea, but I haven't seen it discussed?

Regards
/ Ulrik