Thread overview
LDC 1.6.0
Dec 03, 2017
kinke
Dec 04, 2017
data pulverizer
Dec 04, 2017
Ivan Butygin
December 03, 2017
Hi everyone,

on behalf of the LDC team, I'm glad to announce LDC 1.6. The highlights of this version in a nutshell:

* Based on D 2.076.1.
* Experimental support for dynamic codegen at runtime ('manual JIT').
* Many std.math functions are now CTFE-able.

Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.6.0

Thanks to all contributors!

[LDC master is at v2.077.1.]
December 04, 2017
On Sunday, 3 December 2017 at 12:50:26 UTC, kinke wrote:
> Hi everyone,
>
> on behalf of the LDC team, I'm glad to announce LDC 1.6. The highlights of this version in a nutshell:
>
> * Based on D 2.076.1.
> * Experimental support for dynamic codegen at runtime ('manual JIT').
> * Many std.math functions are now CTFE-able.
>
> Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.6.0
>
> Thanks to all contributors!
>
> [LDC master is at v2.077.1.]

This is awesome news and sound very interesting - my question is will dynamic codegen allow you to do things like this:

```
@dynamicCompile auto myDynamicFunction(immutable string myParam)
{
  @dynamicCompile mixin(makeFun!(myParam));
  return newFunction();
}
```

where `newFunction()` is constructed at dynamic compile-time (during runtime) and its return type as well as the return type of `myDynamicFunction()` is only known once the dynamic compilation is done? So could I call `myDynamicFunction()` and potentially return different types each time it is called?
December 04, 2017
On Monday, 4 December 2017 at 12:47:35 UTC, data pulverizer wrote:

> where `newFunction()` is constructed at dynamic compile-time (during runtime) and its return type as well as the return type of `myDynamicFunction()` is only known once the dynamic compilation is done? So could I call `myDynamicFunction()` and potentially return different types each time it is called?

This is not possible with current design. All high level language processing is still done during compile time and only low-level llvm ir is saved to be optimized and codegened later. Jit runtime knows nothing about language, it only have llvm optimizer and backend.

Implementing high level D code processing during runtime will require pulling D frontend which isn't very well suited to be used as library.