Consider

void foo(string A = "")(string B = "")
{
    static if (A != "")
       do(A);
    else
       do(B);
}

foo!("x");

foo("x");


This is necessary because D's templating and meta programming system is frail.

While CTFE should take care of such things, it does not, consider import(file) vs readText(file).

If do loads such a file then one must use tricks as above:


auto load(string n = "")(string n2 = "")
{
    static if (n != "")
        enum x = import(n);
    else
        auto x = readText(n2);
}

auto load2(string n)
{
       enum x = import(n);
       string y = import(n);
}


load2 fails to compile SIMPLY because n is a RT parameter.

Even if ctfe were to kick in, such as load2("LiteralFileName.txt"), it is irrelevant because we can't compile the code.

So tricks as in load are used, but it is very hacky and verbose to do something very simple and natural.

This is precisely because readText cannot be used at compile time since it dispatches to the OS's reading routines rather than using import. This is not necessarily bad since we generally do not want to import files in to the application at compile time, but when we do it creates somewhat of a mess to unify code under ctfe.

For example, if I create a function that loads a file and processes it at RT then that code will not compile when used in CTFE. If I modify it to import the text at CT then it does not work at RT... even though the single point of breakage is the import/readText line.


auto importOrReadText(string n)
{
    if (__ctfe)
    {
        auto x = import(n);
    } else
    {
        auto x = readText(n);
    }
}

Fails for the same reasons above.

There is no way to get out of this conundrum(and therefor it is a contradiction). It thin requires kicking the can down the street and not read files at all but take text.

My suggestion is for someone to fix this. I'm not sure of the solution.


maybe something like

auto importOrReadText(string n)
{
    if (__ctfe)
    {
        auto x = import(ctfeFix(n));
    } else
    {
        auto x = readText(n);
    }
}

ctfeFix would be a special compiler semantic that takes a RT-like variable and converts it to CT. It does this because it actually can. It knows that n is ctfe'able and therefore n is actually a string literal and will do some "magic" trick the compiler in to seeing n for what it really is.

importOrReadText(rtFilename); // uses readText
importOrReadText("x.txt"); // uses import


Unfortunately __ctfe doesn't seem to actually work well... so I suggest further

auto importOrReadText(string n)
{
    static if (isKACT(n))
    {
        auto x = import(n);
        // or auto x = import(ctfeFix(n));
    } else
    {
        auto x = readText(n);
    }
}

isKACT determines if n is actually known at compile time and marks it n as essentially a CT constant as if it were passed as a template parameter(internally it would probably just convert it to a template parameter as if it were passed as such).


There may be other solutions.





  • CT/RT annoyance Bart via Digitalmars-d-learn

Reply via email to