Parse File at compile time, but not embedded

[Joerg Joergonson via Digitalmars-d-learn]

On Friday, 10 June 2016 at 12:48:43 UTC, Alex Parrill wrote:
> On Thursday, 9 June 2016 at 22:02:44 UTC, Joerg Joergonson 
> wrote:
>> On Tuesday, 7 June 2016 at 22:09:58 UTC, Alex Parrill wrote:
>>> Accessing a SQL server at compile time seems like a huge 
>>> abuse of CTFE (and I'm pretty sure it's impossible at the 
>>> moment). Why do I need to install and set up a MySQL database 
>>> in order to build your software?
>>
>> Lol, who says you have access to my software? You know, the 
>> problem with assumptions is that they generally make no sense 
>> when you actually think about them.
>
> By "I" I meant "someone new coming into the project", such as a 
> new hire or someone that will be maintaining your program while 
> you work on other things.
>
> In any case, this is impossible. D has no such concept as 
> "compile-time-only" values, so any usage of a value risks 
> embedding it into the binary.

It seems that dmd does not remove the data if it is used in any 
way. When I started using the code, the data then appeared in the 
binary.

The access to the code is through the following

auto SetupData(string filename)
{
    enum d = ParseData!(filename);
    //pragma(msg, d);
    mixin(d);
    return data;
}

The enum d does not have the data in it as showing by the pragma. 
ParseData simply determines how to build data depending on 
external state and uses import(filename) to get data.

Since the code compiles, obviously d is a CT constant. But after 
actually using "data" and doing some work with it, the imported 
file showed up in the binary.

Of course, if I just copy the pragma output and paste it in place 
of the first 3 lines, the external file it isn't added to the 
binary(since there are obviously then no references to it).

So, at least for DMD, it doesn't do a good job at removing 
"dangling" references.  I haven't tried GDC or LDC.

You could probably use somethign like

string ParseData(string filename)()
{
    auto lines[] = import(splitLines(import(filename)));
    if (lines[0] == "XXXyyyZZZ33322211")
       return "int data = 3";
    return "int data = 4";
}

So the idea is if the external file contains XXXyyyZZZ33322211 we 
create an int with value 3 and if not then with 4.

The point is, though, that `XXXyyyZZZ33322211` should never be in 
the binary since ParseData is never called at run-time. At 
compile time, the compiler executes ParseData as CTFE and is able 
to generate the mixin string as if directly typed "int data = 3;" 
or "int data = 4;" instead.

The only difference between my code and the above is the 
generated string that is returned.

I'm going to assume it's a dmd thing for now until I'm able check 
it out with another compiler.