Vote on region allocator

[dsimcha]

== Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
> On 26/09/11 7:46 PM, dsimcha wrote:
> > == Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
> >>> T newArray(T, I...)(I sizes);
> >>>
> >>> // Usage:
> >>> auto foo = newArray!(uint[])(5);
> >>>
> >>> This would be marginally do-able but very ugly if RTTI were used.
> >> Ok, now I'm really lost. Where do allocators come into that?
> >
> > I'm sorry.  To clarify:
> >
> > SomeAllocator alloc;
> > auto foo = alloc.newArray!(uint[])(5);
> >
> > The only way to do this with dynamic allocators would be a final templated
> > function wrapping a function that takes RTTI.  This would be marginally do-able
> > but very ugly.
> Why on Earth would an allocator have a newArray method?
> Allocators allocate bytes, they don't construct objects. newArray should
> take an allocator:
> // Template version
> T newArray(A, T, I...)(A allocator, I...);
> // Dynamic version
> T newArray(T, I...)(IAllocator allocator, I...);
> newArray then requests:
> allocator.allocate( /+ bytes +/, /+ align (optional) +/ );
> And constructs the array in those bytes.

This was previously discussed in the review.  The problem is that the allocator
may have a use for the type information, e.g. setting GC flags, etc.