CTFE bug causes null check to pass on null pointers (Issue 7602)

[Jens Mueller]

Don Clugston wrote:
> On 21/03/12 11:22, Jens Mueller wrote:
> > David Nadlinger wrote:
> >> On Wednesday, 21 March 2012 at 09:51:43 UTC, Jens Mueller wrote:
> >>> Interesting. How do I make use of this?
> >>>
> >>> […]
> >>>
> >>> What's the trick to use memory allocated in a CTFE. Say e.g. I
> >>> want to
> >>> build a tree at compile time using CTFE.
> >>
> >> You can't do that right now (i.e. converting CTFE-allocated memory
> >> to initializers for run-time values), but it enables you to use
> >> classes, etc. _during_ CTFE.
> > 
> > Just for clarification:
> > Why do you say "initializers for _run-time_ values"? I believe I just
> > want to allocate memory at compile-time.
> 
> Any heap-allocated object is on the CTFE heap. At runtime, it needs to
> be on the runtime heap. There is currently no mechanism in the back-end
> for transferring data from the CTFE heap to the runtime heap, so it
> currently generates an error message.

That's fine with me. Just want to use new at compile-time.
But being able to move memory from CTFE heap to runtime heap would be
nice and probably finds its uses.

> You can return structs and arrays, because we have struct literals and
> array literals, but there is no such thing as a class literal. CTFE will
> currently allow you to return a class, but only if it is null.

Aha.

> > I just found out you are not allowed to return an instance. But you can
> > use out parameters.
> 
> Oh dear. That sounds like a bug. There is just no way you can
> automatically instantiate a class at runtime, using CTFE data. There
> would need to be code in the runtime to do it, and it just doesn't exist!

I'm doing it all at compile-time. I need to build some data structure
(using pointers) at compile time to generate a string that gets mixed
in.
I think there is no bug. It behaves perfectly as you say.

Many Thanks Don for bringing run-time to compile-time. Making
compile-time programming less awkward.

Jens