built-in script with expression trees or AST

[KnightMare]

subj with
- one shared GC.
- any D-types can be called from script without interop. but it 
should be allowed to call from script engine by module or by 
explicit list of types (we can add types dynamically at runtime). 
exception: script can use (d/w)string and fundamental types 
(ulong, float..). i.e D-types should/can be proxied or 
white-listed not only for types but for some connection-string. 
for example we can allow scripts to use TCP sockets but we allow 
connection to some hosts per host basis. some D-type 
ScriptTCPSocket( string endpoint ) that has white-listed host 
list or some callback to D-code that decide what allow and what 
deny.
- script can use functions and methods with function-pointer. so, 
script cannot use inlined D-functions or uninstantiated 
D-templates.
- script can use same class-object and structs dispositions and 
function calling convention - VTBL, UFCS, operators..
- Dlang compiler itself as runtime script engine is to heavy, so 
script engine use light version with no parser, with no pointer 
types and pointer math.
- when u have AST or expression trees from which script engine 
can generate code (LLVM) u can use any DSL or script types - Lua, 
JavaScript, any what u want.
- with possibility change code on the fly. (how to store current 
living objects and how to restore their VTBL?)
- I thought about WASM engine, but WASM-restrictions disallow 
shared GC and types and adds interop.. so, probably not.

subj looks like Terra-lang for Lua or QScript/QML for Qt, 
Roslyn/Compiler-as-Service for .NET

why it needed built-in script engine as language feature?
again, with such script engine dont need any interop - strings 
and objects in same GC and same type and same VTBL, all same, 
just dynamic code generation that already exists in LDC 
(OFFTOPIC: so LDC can link JIT-code to AOT-code - if JIT calls 
toLower(string) AOT knows where is it(address) and etc - some 
kind of compiler generated MAP of functions).
question still without answer.
u can:
- using scripts as application extension is obvious. generate 
code for user diagrams. from AST we can generate text 
representation of logic for another lang: we have script, it 
works fine, we can generate Dlang code and compile it with AOT to 
new version of application for more benefits without rewriting it 
from Lua to Dlang/R.
- (in case we have GUI-library with some DSL) designers can edit 
WYSIWYG-forms like QML (how will work intellisense for them if 
they want add some data-validator code? need to think). 
Capability of QML is awesome.
- in case u have connection string to DB AOT can generate 
appropriate types for access/modify DB-data with probably default 
forms for editing/viewing with possibility to change such GUI. 
(why not to generate that with some tools and after this step 
compile whole application? need to think. probably wrong 
example). the same can be applied to REST/SOAP services.
- what else?

IMO it will be killer-feature (and I cannot to offer the killer 
use case :)