On Thursday, 21 July 2022 at 04:11:57 UTC, Walter Bright wrote:
> On 7/19/2022 3:30 PM, Hipreme wrote:
>> version(V1_3)
>>      version = V1_2;
>> version(V1_2)
>>      version = V1_1;
>> version(V1_1)
>>      version = V1_0;
>
> This kind of thing is indeed terrible. Fortunately, there are better ways.
>
> Let's say you've got FeatureX, and it exists in some versions and not in others.
>
> Worse way:
>
>     version (X) doX();
>
> Better way:
>
>     import X;
>     doX();
>
> Inside module X:
>
>     module X;
>
>     version (X)
>         void X() { ... }
>     else
>         void X() {}
>
> Now, let's say version Y and Z both rely on X being implemented:
>
>     import X;
>     doX();
>
> module X:
>
>     version (Y) import Ximpl : X;
>     else version (Z) import Ximpl : Y;
>     else void X() { }
>
> module Ximpl:
>
>     module Ximpl;
>
>     void X() { ... }
>
> Essentially, what you wind up with is, for each of the versions, there will be a straightforward list of which features are implemented for it. These manifests only appear once in your code, and are easy to maintain.
>
> The complaint about this comes from the DRY principle, people do not want to duplicate a single line of code (in this case, the import lines). But once one gets past DRY, the readability of each version having its own list begins to look much more attractive.
>
> Even better, when one adds a new version, the addition becomes straightforward rather than weaving it into a tangle of other conditional compilation sections.
>
> I know you're not convinced. But I ask that you think about it, and give it a try. I bet you like the results. And you won't have that conditional compilation mess *per file* anymore.


Okay, so what I asked is not exactly doing as people here thought like:
```d
version(SDL > 2)
```


What I asked is basically, for maintaining the same behaviour we have right now, when defining like SDL.2.5, it would define:

```d
version(SDL.2.5) //Ok
version(SDL.2.4) //Ok
version(SDL.2.3) //Ok
version(SDL.2.2) //Ok
version(SDL.2.1) //Ok
version(SDL.2.0) //Ok
version(SDL.1.9) //Not ok
```

It would basically just insert all possible versions when defining with a number like that, I'm not expecting to use those kind of operators with `version`. I have discussed and many people agree that doing many logical operators (besides `!version` (I do a lot of version(){}else{}) ) is bad.

On Friday, 22 July 2022 at 10:36:39 UTC, Hipreme wrote:

> ```d
> version(SDL.2.5) //Ok
> version(SDL.2.4) //Ok
> version(SDL.2.3) //Ok
> version(SDL.2.2) //Ok
> version(SDL.2.1) //Ok
> version(SDL.2.0) //Ok
> version(SDL.1.9) //Not ok
> ```
>
> It would basically just insert all possible versions when defining with a number like that, I'm not expecting to use those kind of operators with `version`. I

Then what happens when you *don't* want old versions together with the new one?

On Friday, 22 July 2022 at 10:43:03 UTC, Mike Parker wrote:
> On Friday, 22 July 2022 at 10:36:39 UTC, Hipreme wrote:
>
>> ```d
>> version(SDL.2.5) //Ok
>> version(SDL.2.4) //Ok
>> version(SDL.2.3) //Ok
>> version(SDL.2.2) //Ok
>> version(SDL.2.1) //Ok
>> version(SDL.2.0) //Ok
>> version(SDL.1.9) //Not ok
>> ```
>>
>> It would basically just insert all possible versions when defining with a number like that, I'm not expecting to use those kind of operators with `version`. I
>
> Then what happens when you *don't* want old versions together with the new one?

I'm thinking about newer versions with incremental additions.
When I was looking into directx-d bindings, most of newer version depends on older version unless they change its major. The same thing could be applied to:

```d
version(SDL.2.5.5)
...
version(SDL.2.5.0) //Ok
version(SDL.2.4) //not ok
```

On Friday, 22 July 2022 at 13:36:37 UTC, Hipreme wrote:

> I'm thinking about newer versions with incremental additions.
> When I was looking into directx-d bindings, most of newer version depends on older version unless they change its major. The same thing could be applied to:
>
> ```d
> version(SDL.2.5.5)
> ...
> version(SDL.2.5.0) //Ok
> version(SDL.2.4) //not ok
> ```

And then you're baking a library versioning scheme into the language. Not sure about that.

On 7/22/2022 3:36 AM, Hipreme wrote:
> Okay, so what I asked is not exactly doing as people here thought like:
> ```d
> version(SDL > 2)
> ```
> 
> 
> What I asked is basically, for maintaining the same behaviour we have right now, when defining like SDL.2.5, it would define:
> 
> ```d
> version(SDL.2.5) //Ok
> version(SDL.2.4) //Ok
> version(SDL.2.3) //Ok
> version(SDL.2.2) //Ok
> version(SDL.2.1) //Ok
> version(SDL.2.0) //Ok
> version(SDL.1.9) //Not ok
> ```
> 
> It would basically just insert all possible versions when defining with a number like that, I'm not expecting to use those kind of operators with `version`.

I know, this is an 'OR' operation. My proposal is a better way of doing this.

> I have discussed and many people agree that doing many logical operators (besides `!version` (I do a lot of version(){}else{}) ) is bad.

!version is something I try to destroy. Versions should be positive affirmations, not negative ones. For example,

version(DEMO) ... do demo stuff...

!version(DEMO) ... do release stuff ...

Better is to have `version(RELEASE)`. Even better, version the feature itself that you're turning on.

Rationale: I've seen endless `#if CompilerVersion > 6` in C with all kinds of versions, and the poor reader has no idea what features are being turned on and off with them.

On 7/22/2022 6:36 AM, Hipreme wrote:
> version(SDL.2.5.5)
> ...
> version(SDL.2.5.0) //Ok
> version(SDL.2.4) //not ok

The reader has no idea what actual feature is being turned on or off.

On 7/21/22 1:51 AM, Ola Fosheim Grøstad wrote:
> Seems like you have encouraged people to avoid using ‘version’ and inventing their own schemes. So you got a many different chaotic expressions of versioning instead of a singular one. 
I find this very insightful; the practical consequences of well-meaning policies are often surprising and frequently the complete opposite of the original policy's intent.