CT/RT annoyance
Bart
Bart at gmail.com
Mon Jun 17 05:04:50 UTC 2019
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.
More information about the Digitalmars-d-learn
mailing list