On Saturday, 4 February 2017 at 10:27:58 UTC, Stefan Koch wrote:
> std.conv.to is no longer blacklisted.
> since I now bail on every string foreach.
> As soon as ctfeable utf-conversion functions are in place, newCTFE can be used for fast low-memory overhead comptiletime parsing.

Also I just enabled &&.
It's still experimental but it seems to work sofar.

On Saturday, 4 February 2017 at 11:32:52 UTC, Stefan Koch wrote:
> On Saturday, 4 February 2017 at 10:27:58 UTC, Stefan Koch wrote:
>> std.conv.to is no longer blacklisted.
>> since I now bail on every string foreach.
>> As soon as ctfeable utf-conversion functions are in place, newCTFE can be used for fast low-memory overhead comptiletime parsing.
>
> Also I just enabled &&.
> It's still experimental but it seems to work sofar.

experiment failed.
Not necessarily because AndAnd itself is wrong but rather because something that is now not bailed out on, puts us in a bad state.
I will disable && for the time being and continue working on the function argument problem.

I can present you a nice snippet that just compiled with newCTFE

On Saturday, 4 February 2017 at 16:30:30 UTC, Stefan Koch wrote:
> I can present you a nice snippet that just compiled with newCTFE

int[] makeAndInitArray(int until)
{
  int[] result;
  result.length = until;

  foreach(i; 0 .. until)
  {
    result[i] = i;
  }

  return result;
}


int[] filter(alias filterFn)(int[] arr)
{
  int[] result;
  result.length = arr.length;

  uint resultLength;
  foreach(i;0 .. arr.length)
  {
    auto e = arr[i];
    if (filterFn(e))
    {
      result[resultLength++] = e;
    }
  }

  result.length = resultLength;
  // I cannot remember implementing it but shrinking seems to work
  return result;
}
enum arr_500_000 = makeAndInitArray(500_000);

static assert(arr_500_000.filter!(e => !(e % 3)));
static assert([1,2,3,4,5,6,7,8,9,10,11,12,13].filter!(e => !(e % 3)) == [3,6,9,12]);


newCTFE takes a quarter of the time, and only half of the memory.
It would go even faster if we did not create the enum arr_500_000 but instead do that in a function-local variable.

because then the array does not allocate 500_000 expression nodes.

Function pointers and other advanced features interfere with the ability to cache bytecode I just never noticed because the bytecode caching feature was disabled a long time.
Since I do not know how much of it is bitrot I removed it alltogether.
This feature will return and be more performant, when the outside function-arguments are getting fixed.
When this is done we can also remove a few special cases for the interpreter backend which is always good.

Do I understand it right that union at compile time takes space equal to the sum of sizes of its members instead of the size of the largest member?

On Wednesday, 8 February 2017 at 14:01:33 UTC, Kagamin wrote:
> Do I understand it right that union at compile time takes space equal to the sum of sizes of its members instead of the size of the largest member?

generally it takes as much space as the largest member.
Why do you ask ?
And in what context ?

On Wednesday, 8 February 2017 at 14:03:13 UTC, Stefan Koch wrote:
> generally it takes as much space as the largest member.
> Why do you ask ?
> And in what context ?

Asking about memory consumption.
I thought it allowed access to overlapped fields, now I see it doesn't.

I just re-enabled << and >> for 32bit values, as they should not behave differently when applied to mixtures of 32bit and 64bit values.

Furthermore I fixed a few performance issues in the interaction between the interpreter and the bytecode-gen.

I also took the first steps for utf8/32 support.

32bit linux now fails on travis and the autotester.
I cannot reproduce this on my local setup therefore I deduce that it is a regression in the dmd version that is used on those platforms.

I just encountered a familiar problem again ...

uint fn(uint a)
{
    final switch(a)
    {
        case 1 :
            do
            {
                a++;
                if (a == 17) break;
            } while(a < 20);
                return a;

        case 2 : return 1;
    }
}

static assert(fn(1) == 17); // fails because the return is 20
static assert(fn(2) == 1);

It turns out I forgot use the facility I implemented to handle this on DoStatements as well.
This is now fixed.

I am currently working on && again,
So far I hit a curious situation when handling
(b1 && b2 && b3)
everything works fine except that b3 will be evaluated 3 times.
It's a puzzler :)