deprecated delete and manual memory management

[Dmitry Olshansky]

On 27.04.2011 20:21, Ulrik Mikaelsson wrote:
> 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

I presonally  think of new in D  as a shortcut for yours would be 
GC.new!T(...). It's the same thing as with 'foreach' and such, i.e. used 
often enough to deserve a keyword.

As for your suggestion, I see some problems with it:
- yours Malloc and GC artifacts already have asymmetry, imagine generic 
code. Also there is stack-like allocators e.g. new David Simcha's TempAlloc
- there is an awful lot of operations which allocate GC memory 
implicitly aka arr1 ~ arr2, so it's not like you can pass the allocator 
and prevent the function from allocating _somewhere_ else
- I still fail to see how passing allocator would allow the function to 
decide on whether it's GC-like allocation or not, i.e. manual memory 
management implies the certain way function does its job (more generally 
the whole program, framework, module etc. it's not something decided at 
single call point)

-- 
Dmitry Olshansky