version(number) actually contains something really nice on it. But it is useless.

For example: version(3) would actually declare version(2) and version(1).

The problem is that these doesn't mean anything at all, but they have this property of waterfall. Which is totally missing in D right now. Take this as an example:

version(V1_3)
    version = V1_2;
version(V1_2)
    version = V1_1;
version(V1_1)
    version = V1_0;

I need to do this. per file. This is such a boilerplate code that could get a lot nicer if we had some kind of versioning syntax. For example version(V.1.3). We could even get:
version(SDL.2.5). Which would declare everything down to SDL.2.0

Obviously this feature is meaningless to small projects

On Tuesday, 19 July 2022 at 22:30:28 UTC, Hipreme wrote:

IMO it is completely useless: what does "3" mean? what is relationship between "3" in my package and "3" in dependency? what is relationship between "3" in different sources within the same package?

version(V1_3)
    version = V1_2;
version(V1_2)
    version = V1_1;
version(V1_1)
    version = V1_0;

I don't like it - why can't we just write this instead?

version(V1 >= 3)
    pragma(msg, "newest version");
else version(V1 >= 2)
    pragma(msg, "old version");
else
    pragma(msg, "obsolete version");

But having this would mean that D has two ways to express the same things: version and static if because that code is the same as:

static if(V1 >= 3)
    pragma(msg, "newest version");
else static if(V1 >= 2)
    pragma(msg, "old version");
else
    pragma(msg, "obsolete version");

Again, why can't it be version(V >= 1.3) or static if(SDL >= 2.5)?

I actually have a question since this topic is brought up:
What is conceptual difference between version(FOO) and static if(FOO)? I see version is a very limited comparing to static if - the former checks for "boolean" result (whether an ID is defined) while the latter evaluates condition expression.

On 7/19/22 9:22 PM, Andrey Zherikov wrote:

version is specifically a replacement for #defines as in C. They are specified mostly on the command line.

But also, a version cannot be detected from an imported file -- every module starts with the compilation versions, and that's it.

Walter was very averse to the mess that is C preprocessor defines, and wanted something more hygienic.

The thing I miss the most for versions is a version1 or version2 mechanism. I doubt we will ever convince Walter this is a good idea.

But in any case, we have the numeric versions, which are 100% useless (because, as you say, they are not scoped to any dependencies), it would make sense to at least make that feature useful.

-Steve

On Wednesday, 20 July 2022 at 01:22:00 UTC, Andrey Zherikov wrote:

Consider:

enum Test = true;

void main() {
    import std.stdio : writeln;

    version(Test) {
        writeln("true");
    } else {
        writeln("false");
    }
}

And this output:

$ dmd -run example.d
false
$ dmd -version=Test -run example.d
true

A few seconds of hacking with a build system though, and static if seems to be enough:

import mbs = magic_buildsystem_definitions;

enum Test = true;

void main() {
    import std.stdio : writeln;

    static if (mbs.Test) {
        writeln("true");
    } else {
        writeln("false");
    }
}

with that module generated of course by the build system, and any logic you like now capable.

version's limited expressiveness is due to experience with #ifdef abuse in C, much like (I imagine) limitations like "the code won't even compile if you're not using an import" exists in Go. You could positively say that such limitations are lessons learned and you could negatively say that they're expressions of trauma.

On Wednesday, 20 July 2022 at 01:34:00 UTC, Steven Schveighoffer wrote:

It's not a full replacement because it doesn't support -DSOME_DEFINE=5 or -DANOTHER_DEFINE="some string".

One of the features which I really miss in D is inability to do these things. This is very largely used in software development for setting compile-time constants from command line. D doesn't support this out of the box (I have to dump a .d file with set of enums and then include it into the build).

I'm totally for simple and clean solution here but whatever D offers right now is half-baked IMHO.

I don't think that version1 or version2 is any different than allowing complete conditional expression.

I don't see how raw numbers can be useful. Could you clarify your idea?

On Wednesday, 20 July 2022 at 02:10:21 UTC, Andrey Zherikov wrote:

And that works, right? When you definitely need the feature, enough to live with a build-system burden like this, then you can have it. And when you don't definitely need it, D's version feature doesn't let you casually, effortlessly, create an impossible to understand version soup.

Meanwhile, D makes it trivially easy to add a unit test whenever you want, and in some other languages unit testing is a feature that requires you to bear the burden of a more complex build system.

You can see the opinions of the language designers. Testing is so important that even a throwaway function posted to this forum can have a unittest{} with it. Elaborate build-time configuration is so detested that you have to ignore the relevant language feature and roll your own alternative to it.

On Wednesday, 20 July 2022 at 01:38:41 UTC, jfondren wrote:

import mbs = magic_buildsystem_definitions;

enum Test = true;

void main() {
    import std.stdio : writeln;

    static if (mbs.Test) {
        writeln("true");
    } else {
        writeln("false");
    }
}

I'd like build system to not generate any files with compile-time constants.

I'm not sure I got what #ifdef issue is referenced. Is it something like the one described in https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf?

On 7/19/22 10:10 PM, Andrey Zherikov wrote:

Yes, and actually, this is not something I miss terribly. One place where I do miss it is communicating something like git version information to the compiler. The only way to do this is to pre-build a module for it.

version(a) version(b) accomplishes a && b. But a || b is just a complete pain to write.

The proposal here (I think) is that if you define version MyLibrary.5 then version(MyLibrary.4) or version(MyLibrary.1) all are enabled.

What the current system does is worthless, because version(5) has no meaning. If we scope the numbers to be within a specific project, then that project has the ability to define what those things mean, and you can just define one version on the command line.

-Steve

On Wednesday, 20 July 2022 at 01:38:41 UTC, jfondren wrote:

enum Test = true;

void main() {
    import std.stdio : writeln;

    version(Test) {
        writeln("true");
    } else {
        writeln("false");
    }
}

$ dmd -run example.d
false
$ dmd -version=Test -run example.d
true

import mbs = magic_buildsystem_definitions;

enum Test = true;

void main() {
    import std.stdio : writeln;

    static if (mbs.Test) {
        writeln("true");
    } else {
        writeln("false");
    }
}

It is virtually impossible to recreate the mess macros done. They were so messy because one could define AND undefine them, which made tracking a lot hard.

Even worse, macros were used for everything. Constants, inline functions, templates, syntax transformers, aliases, conditional compilation, importing.

D has already solved that by creating specific tool for each thing, giving a way to define version as a namespaced number would hardly make anything more complex. If you take the use case i bring for example, you you actually check it would make it easier to understand