On Mon, Sep 23, 2013 at 07:29:39PM -0400, Nick Sabalausky wrote:
> On Mon, 23 Sep 2013 17:02:09 +0200
> "Adam D. Ruppe" <destructiona...@gmail.com> wrote:
> 
> > We should really deprecate the new keyword. It'd break like all 
> > code ever, but with D's templates, there's no need for it, and 
> > when it is there, it is going to spark problems about replacing 
> > global allocators or the library allocators being second class 
> > citizens.
> > 
> 
> I think that's addressing the wrong problem, it wouldn't solve much,
> if anything. We'd just end up with a lot of lib writers (and others)
> hardcoding in usage of the default allocator. So it'd be exactly the
> same as now, just with uglier syntax and a ton of breakage.
> 
> What's ultimately needed is a way to change the default allocator for
> not only "new" but also array concatenation, closures, and any other
> part of the language that might allocate. That way, we actually *do* get
> the benefits we're looking for, plus we keep the nicer current syntax
> and no breakage.
> 
> tl;dr: "new" is a red herring. The real issue is being able to easily
> replace the default allocator.

I thought Walter's DIP already addresses the issue of replacing the
default allocator?

        http://wiki.dlang.org/DIP46

I get the feeling that we don't have a good handle on the fundamental
issues, though. Having a stack for managing the default allocator works
for the simpler cases, but it's unclear how things would interact once
you throw in other requirements, like class/struct-scoped allocators,
block scoped allocators inside closures, user-specified allocators that
must interact with the foregoing, etc..

For example, it's relatively easy to understand this:

        void doWork() {
                gc_push(MyAlloc);
                scope(exit) gc_pop();
                ... // do work
        }
        void doMoreWork() {
                gc_push(AnotherAlloc);
                scope(exit) gc_pop();
                ... // do work
        }
        void main() {
                doWork();
                doMoreWork();
        }

But once you throw in closures and delegates, things become rather murky:

        auto getCallback() {
                gc_push(MyAlloc);
                scope(exit) gc_pop();

                int closed_var;
                return {
                        // What does this do?
                        closed_var++;

                        string x = "abc";
                        x ~= "def"; // which allocator does this use?
                };
        }
        void main() {
                auto dg = getCallback();
                gc_push(OtherAlloc);
                scope(exit) gc_pop();
                dg();           // Hmm...
        }


T

-- 
May you live all the days of your life. -- Jonathan Swift

Reply via email to