On Wednesday, 26 June 2013 at 14:59:41 UTC, Dmitry Olshansky
wrote:
Here is a chief problem - the assumption that is required to
make it magically work.
Now what I see is:
T arr[];//TLS
//somewhere down the line
arr = ... ;
else{
...
alloctor(myAlloc){
arr = array(filter!....);
}
...
}
return arr;
Having an unsafe magic wand that may transmogrify some code to
switch allocation strategy I consider naive and dangerous.
Who ever told you process does return before allocating a few
Gigs of RAM (and hoping on GC collection)? Right, nobody. Maybe
it's an event loop that may run forever.
What is missing is that code up to date assumes new == GC and
works _like that_.
Not magic, but the tool which is quite powerful and thus it may
shoot your leg.
This is unsafe, but if you want it safe, don't use allocators,
stay with GC.
In the example above, you get first arr freed by GC, second arr
may point to nothing if myAlloc was implemented to free it
before. Or you may get a proper arr reference if myAlloc used
malloc and didn't free it. The fact that you may write bad code
does not make the language (or concept) bad.
