On Sunday, 25 December 2016 at 11:27:07 UTC, Stefan Koch wrote:
>> static immutable alr = arrayLiteralReturn();
>> static assert(alr == [1,2,3]);
>
> There were a few problems with that.
> Namely some arrays-literals would not have a length.
> This is because of literals coercing to slices.
> This bug is now fixed, at the expense of registering more types then is strictly necessary.
> Also it creates null holes in the TypeArrays.
> This may might be painful in the future.
> But for now, global Array-literals work.

There are sill problems when you try to index those arrays for function calls.
This can be fixed by proving a different code-path.
If those arrays are indexed as function-parameters at the top level.

On Sunday, 25 December 2016 at 12:21:42 UTC, Stefan Koch wrote:
> On Sunday, 25 December 2016 at 11:27:07 UTC, Stefan Koch wrote:
>>> static immutable alr = arrayLiteralReturn();
>>> static assert(alr == [1,2,3]);
>>
>> There were a few problems with that.
>> Namely some arrays-literals would not have a length.
>> This is because of literals coercing to slices.
>> This bug is now fixed, at the expense of registering more types then is strictly necessary.
>> Also it creates null holes in the TypeArrays.
>> This may might be painful in the future.
>> But for now, global Array-literals work.
>
> There are sill problems when you try to index those arrays for function calls.
> This can be fixed by proving a different code-path.
> If those arrays are indexed as function-parameters at the top level.

I reverted my ArrayLiteral fixes for now,
they broke the druntime build.

On Sunday, 25 December 2016 at 15:26:36 UTC, Stefan Koch wrote:

> I reverted my ArrayLiteral fixes for now,
> they broke the druntime build.

So far by attempts to fix this situation, proved fruitless.
However this getting global static variables to work correctly is a high-priority goal, as it is both important for the typical use-cases of ctfe and it affects the overall design of the engine.

I'll be taking a short rest during the next days, hopefully I will know how to move forward after that.

Also I need to prepare a talk-proposal for next dconf.

Hi Guys,

I just figured out why array constants did not work as function arguments.
It's because the array-constant undergoes a cast when used as slice, while an array literal can be taken as is.

The currently newCTFE does not really provide the capabilities to handle casts.
This is another issue that has to be addressed before function-calls come into play.

Within the engine dynamic and static arrays are represented in the same structure.
Therefore we don't need to take action on such a cast as long as the element types are the same.

While simply ignoring the cast-expression is correct in the case, I need to systemize the handling of casts better.

On Thursday, 29 December 2016 at 18:21:30 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I just figured out why array constants did not work as function arguments.
> It's because the array-constant undergoes a cast when used as slice, while an array literal can be taken as is.
>
> The currently newCTFE does not really provide the capabilities to handle casts.
> This is another issue that has to be addressed before function-calls come into play.
>
> Within the engine dynamic and static arrays are represented in the same structure.
> Therefore we don't need to take action on such a cast as long as the element types are the same.
>
> While simply ignoring the cast-expression is correct in the case, I need to systemize the handling of casts better.

This is now partially fixed.

Also all the latest work was merged in the feature branch.

The current timeline is still the same, I suspect that newCTFE will be usable in February.

global immutable integer Arrays are now completely functional!

This makes the following code work:
uint echo (uint val)
{
    return val;
}

const(uint) fastLog10(const uint val) pure nothrow @nogc {
    return      (val < 10) ? 0 :
                (val < 100) ? 1 :
                (val < 1000) ? 2 :
                (val < 10000) ? 3 :
                (val < 100000) ? 4 :
                (val < 1000000) ? 5 :
                (val < 10000000) ? 6 :
                (val < 100000000) ? 7 :
                (val < 1000000000) ? 8 : 9;
}

/*@unique*/ static immutable uint[10] fastPow10tbl = [
        1,
        10,
        100,
        1000,
        10000,
        100000,
        1000000,
        10000000,
        100000000,
        1000000000,
] ;

static assert(fastLog10(fastPow10tbl[2]) == 2);
static assert(fastLog10(fastPow10tbl[3]) == 3);
static assert(fastLog10(1000) == 3);

static assert(echo(fastPow10tbl[1]) == 10);

On Saturday, 31 December 2016 at 16:32:42 UTC, Stefan Koch wrote:
> global immutable integer Arrays are now completely functional!

Great work!

> /*@unique*/ static immutable uint[10] fastPow10tbl = [

BTW: What role does @unique play here?

On Saturday, 31 December 2016 at 17:12:22 UTC, Nordlöw wrote:
> On Saturday, 31 December 2016 at 16:32:42 UTC, Stefan Koch wrote:
>> global immutable integer Arrays are now completely functional!
>
> Great work!
>
>> /*@unique*/ static immutable uint[10] fastPow10tbl = [
>
> BTW: What role does @unique play here?

No role at all. It's a comment.

I have these comments in my tests, to remind myself of certain properties.
That, when properly detected, can lead to better generated code.

So guys.

basic function-calls are supported.

Hell YEAH!

On Monday, 2 January 2017 at 18:40:44 UTC, Stefan Koch wrote:
> So guys.
>
> basic function-calls are supported.
>
> Hell YEAH!

Meaning this will compile :

uint caller(uint n)
{
  return callee(n, 2);
}

uint callee(uint a, uint b)
{
  return a*b;
}

static assert(caller(3) == 6);
static assert(caller(24) == 48);


uint rfn(uint n)
{
  if (n) return n + rfn(n-1);
  return 1;
}

pragma(msg, rfn(2000));