Programming Language for Games, part 3

[Rikki Cattermole via Digitalmars-d]

> * D does the check function thing using compile time function execution
> to check template arguments.
>
> * D also has full compile time function execution - it's a very heavily
> used feature. It's mainly used for metaprogramming, introspection,
> checking of template arguments, etc. Someone has written a ray tracer
> that runs at compile time in D. D's compile time execution doesn't go as
> far as running external functions in DLLs.

The video has actually got me thinking about how we can expand CTFE's 
capabilities while also keeping it secure-ish.

As an example having blocks such as:

__ctfe {
	pragma(msg, __ctfe.ast.getModules());
}

Could output at compile time all the modele names that's being compiled 
currently.
The way I'm looking at it is that files act how they do now but will 
ignore __ctfe blocks unless that file was passed with e.g. -ctfe=mymodule.d

Of course how we get symbols ext. into it is another thing all together. 
Compiler plugin? maybe. Or we do the dirty and go for extern support.

> * D has static assert, which runs the code at compile time, too. The
> space invaders won't run at compile time, because D's compile time code
> running doesn't call external functions in DLLs. I actually suspect that
> could be a problematic feature, because it allows the compiler to
> execute user supplied code which can do anything to your system - a
> great vector for supplying malware to an unsuspecting developer. The
> ascii_map function will work, however.

You really don't want arbitrary code to run with access to system libs. 
Agreed.

A __ctfe block could be rather interesting in that it can only exist at 
compile time and it is known it will execute only when it is passed via 
-ctfe.

Could also remove part of my need for livereload where it creates a file 
specifically to tell the binary what modules is compiled in. Not to 
mention gets round the whole but how do you know its the final 
compilation yada yada ya. Doesn't matter.

In the context of dub, to make it safe by default just require a 
--with-ctfe switch on e.g. build.

For people like me this would be really huge. Like ridiculously. But at 
the same time, I don't believe its a good idea to make it so easy that 
we have people writing games to run at compile time and being multi 
threaded.

Of course this does raise one question, about __traits compared to 
__ctfe.ast functionality.
Could be a little double up ish but at the same time, you shouldn't be 
able to use __ctfe.ast outside of a __ctfe block. For reference, 
__traits is a missing a LOT to the point I couldn't properly create a 
ctfe uml generator.

So recap: suggestion allowing __ctfe blocks that can run code at compile 
time which can utilise external code such as c functions. But to add 
them they must be specifically enabled on the compiler.
The purpose of having such functionality is for generation of document 
or registration of routes without any form of explicit registration.
Perhaps even going so far as to say, don't bother importing e.g. Cmsed 
if you use @Route UDA on a function.
Needs to be refined a lot, but could open up a lot of opportunities here.