Kill version ideas

[IgorDeepakM]

I want to start discussion regarding the "Kill `version`" change.

https://dpldocs.info/opend/roadmap.html

This is something that will affect the code all over the place so I want to start this discussion early to understand what we are aiming for. Druntime is long overdue for an overhaul and I think that new compiler defines are key in order to pursue that goal.

I will explain a little bit what I have in mind. Basically, version is too limited which is already acknowledged so I rather have in mind a key/value par, much similar to C defines. I also want to extend the usage.

First in order to define compile defines as compiler options, just easily
dmd -cdef=mydefinition:value

In order to use the definition in the code we can use existing static if. All the boolean operators are supported as normal. The keyword "cdef" tells the compiler to look for the compiler definition of a given name.

static if (cdef("mydefinition") && cdef("mydefinition2"))
{
    ...
}

This will check if the definition exists.
Checks for values are also supported.

static if (cdef("arch.cpu")  == "x86" && cdef("arch.cpu") == "x86_64")
{
    ...
}

Something I'm interested in is having a contains method in order to search for a substring. Possibly we need to convert to a list of tokens based on a separator.

-cdef=arch.cpu.features:"MMX,SSE,SSE2,..."

static if (cdef("arch.cpu.features").contains("MMX"))
{
    ...
}

Another thing that is useful is being able to include the values of the defines in a mixin or without a mixin.

writeln("This library was compiled for " ~ cdef("arch.cpu") ~ ".");

It should possible to convert the value of a define to a number. We need a standard for this as it could be of any format on the command line, like 1234 or 0x1234.

immutable int PageSize = cdef(pagesize).parse!int()

These are just examples what I'm interested in. The syntax and keywords are just examples and are for me not set in stone. Tell me what you have in mind.

[adamdruppe]

Indeed, there was an upstream PR to add a command line constant thing that would do this same kind of thing:

dlang/dmd#15257

I'm.... a little iffy on if that's a good idea though. There's a lot I like about that PR though: its module scoping is good so you don't accidentally define something used by another library. You can use it with static if, define some specific hooks in the code for documentation, etc.

The big reason why I'm iffy though is that there is another alternative: a config module that users can edit, to put the value right inside D code directly. I need to write a full comparison thing both to explain it and to look in for myself if it is actually better but basically you'd like

module mything.config;
import mything.config_options; // it defines the Cpu type etc in here

enum arch = Cpu(
     features: Cpu.Features.MMX, Cpu.Features.SSE
);

yada yada yada - that is, define it all as D code so you can use structs, enums, etc. to help force data being correct (and reflect on it to make options controls, help screens, documentation pages, etc). The library then import mything.config;, with the user's provided module on the command line taking precedence over the default, and reads the values that way. I wrote a lil more about this in the D Cookbook too btw.

[IgorDeepakM]

Honestly, I think that config files can in many ways be better than compiler defines on the command line.

First, it reduces the command line length as you don't need to put them in the command.

The programmer can more easily get an idea what different configuration options are available by looking at the config file. With compiler defines they are scattered all over the code.

[adamdruppe]

yeah, i like the file in a lot of ways but it also painful when you just want to change one thing or if it changes frequently between builds and such so it isn't always a clear win...

[quickfur]

There should be a 1-to-1 correspondence between editing the config file and specifying them on the command-line. (The syntax doesn't have to be same, in fact probably won't be the same, but the point is that it should be a 1-to-1 correspondence.)

You should also be able to specify different config files on the command line, so that you can e.g. have one config for the Windows build, another for the Linux build, etc.. Like you described above.