What does this compile-time error mean?

[Maxim Fomin]

On Sunday, 24 February 2013 at 09:00:17 UTC, Jonathan M Davis 
wrote:
> Because main_cont is module-level variable, it must be 
> initialized with a
> value at compile time. Classes can be used at compile time (at 
> least some of
> the time), but they cannot stick around between compile time 
> and runtime,
> meaning that you could potentially use them in a CTFE function, 
> but you can't
> initialize a module-level or static variable (or enum) with 
> them, and you're
> attempting to initialize maint_cont with a RedBlackTree, which 
> is a class. It
> won't work.
>
> - Jonathan M Davis

I would say that it is arbitrary restriction

class C { }
struct S { int[] array; this(int val[]) { array = val; } }

//can issue call to runtime allocator
enum EA : int[]
{
     //does not complain that gc_malloc() is absent
     A = [1, 6]
}
//can evaluate dynamically allocated referenced type  at CT
static assert(EA.init == [1, 6]);

// can have module-level object
// evaluated to non-trivial CTFE initializer
EA ea;

enum ES : S
{
     //can issue call to constructor
     A = S([2, 9])
}
// can evaluate this
static assert (ES.init.array == [2, 9]);

// can have module-level object
// evaluated to non-trivial CTFE initializer
ES es;

//but classes don't work
enum EC : C
{
     // B = new C //NG - why not here?
     // why cannot call ga_malloc here?
     A = null
}

void main()
{
     assert(ea == [1, 6]);
     assert(es.array == [2, 9]);
     C c;
     int[] arr;
     assert (c is null && arr is null);
     EA e;
     assert(e !is null && e == [1, 6]);
}

In short, if interpreter can dynamically allocate reference types 
like dynamic arrays, store them in TLS storage and interpret 
trivial CTFE struct constructor, it can handle classes. At least 
it can work without gc_malloc source.