I have not seen any example where version has several OR matches.

Example idiom:

version(X86_64 || X86)
{

}
else version(ARM || Thumb)
{

}...

you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?

On 3/18/20 12:23 PM, IGotD- wrote:
> I have not seen any example where version has several OR matches.
> 
> Example idiom:
> 
> version(X86_64 || X86)
> {
> 
> }
> else version(ARM || Thumb)
> {
> 
> }...
> 
> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?

No, it's not possible. And it won't ever be possible, Walter is dead-set against it. If you want to know the history, look waaaay back in the forums. This question comes up every so often.

There is a workaround though:

template v(string versionID)
{
   mixin("version(" ~ versionID ~ ") enum v = true; else enum v = false;");
}

static if(v!"X86_64" || v!"X86")

...

-Steve

On Wednesday, 18 March 2020 at 16:23:26 UTC, IGotD- wrote:
> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?

The usual workaround is to define a common version, e.g.

version(X86)
    version = X86_ANY
version(X86_64)
    version = X86_ANY

version(X86_ANY)
{
// your code here
}

https://issues.dlang.org/show_bug.cgi?id=19495#c1

On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via Digitalmars-d-learn wrote:
> I have not seen any example where version has several OR matches.
>
> Example idiom:
>
> version(X86_64 || X86)
> {
>
> }
> else version(ARM || Thumb)
> {
>
> }...
>
> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?

To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms.

In general, I think that Walter's approach here is probably the right one, but it can certainly be annoying in cases where you have to duplicate code that actually is the same rather than being subtly different, and a lot of people dislike it enough that they use workarounds like those discussed in this thread.

And of course, some of the same bugs that come up with #ifdefs come up with static ifs in generic code (particularly with range-based code that changes what it's doing based on arange's type), but at least those can be found with thorough tests on a single platform, whereas version-related bugs tend to require that you run thorough tests on each platform.

- Jonathan M Davis

On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote:
> On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via Digitalmars-d-learn wrote:
>> I have not seen any example where version has several OR matches.
>>
>> Example idiom:
>>
>> version(X86_64 || X86)
>> {
>>
>> }
>> else version(ARM || Thumb)
>> {
>>
>> }...
>>
>> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?
>
> To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms.

What kind of bugs are those?

> In general, I think that Walter's approach here is probably the right one, but it can certainly be annoying in cases where you have to duplicate code that actually is the same rather than being subtly different, and a lot of people dislike it enough that they use workarounds like those discussed in this thread.


Sadly it still shares probably the worst bug with the C preposser in that anything that isnt defined simply evaluates to false. If you have a typo then the code will still "work". His approach only works if you can put an assert in the else branch. Which is the case for C/C++ as well. That isnt always possible, as a result you still have the same problem with typos.

> And of course, some of the same bugs that come up with #ifdefs come up with static ifs in generic code (particularly with range-based code that changes what it's doing based on arange's type), but at least those can be found with thorough tests on a single platform, whereas version-related bugs tend to require that you run thorough tests on each platform.
>
> - Jonathan M Davis

You still need to test your code on those platforms, so if you are supporting them you still have related problems.

On Friday, March 20, 2020 4:33:58 PM MDT jxel via Digitalmars-d-learn wrote:
> On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote:
> > On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via
> >
> > Digitalmars-d-learn wrote:
> >> I have not seen any example where version has several OR matches.
> >>
> >> Example idiom:
> >>
> >> version(X86_64 || X86)
> >> {
> >>
> >> }
> >> else version(ARM || Thumb)
> >> {
> >>
> >> }...
> >>
> >> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?
> >
> > To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms.
>
> What kind of bugs are those?

There are a variety of issues that come from it, and it's been discussed at length in past threads (and much better than I'll explain here, I'm sure), but the main issues stem from the fact that when you're writing code that is platform-dependent but using it on multiple platforms, it can become really easy to break stuff as the code is altered over time. e.g. you can make a change that works perfectly fine on the platform that you're developing on without realizing that it won't work on the other platforms sharing the same #ifdef block, and while you should be testing such code on all supported platforms, it often doesn't happen, and even when it does happen, it's usually much further down the line after many more changes have been made. It would be highly abnormal for someone to test what they're working on on all of the relevant platforms as they're working on it.

It also can get really tricky to avoid subtle bugs once you start having more complex boolean expressions and/or have nested #ifdefs. That's where things tend to get _really_ bad. Another big problem comes in when you just assume that the code from one platform will work with another and alter existing #ifdefs to be used on the new platform. Suddenly code that was only supposed to be used on one platform is being used on multiple, and it can cause big problems depending on what that code actualy does and what assumptions were made when writing it. By simply following the basic idiom of

version(A)
{
}
else version(B)
{
}
else
    static assert(false, "Platform not supported");

you avoid problems that stem from code being used an a platform that it's not intended for, and you get compilation errors if you try to use code on a platform that it wasn't made to work on yet. It can result in more code duplication than many people like, but it's ultimately less error-prone. Either way, in general, it's far better to design your code such that as little of it as possible is platform-dependent and that those parts that are are well-encapsulated.

- Jonathan M Davis

On Saturday, 21 March 2020 at 00:12:20 UTC, Jonathan M Davis wrote:
> On Friday, March 20, 2020 4:33:58 PM MDT jxel via Digitalmars-d-learn wrote:
>> On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote:
>> > On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via
>> >
>> > Digitalmars-d-learn wrote:
>> >> I have not seen any example where version has several OR matches.
>> >>
>> >> Example idiom:
>> >>
>> >> version(X86_64 || X86)
>> >> {
>> >>
>> >> }
>> >> else version(ARM || Thumb)
>> >> {
>> >>
>> >> }...
>> >>
>> >> you get the idea. So is this possible at all or do you have to duplicate the code for each version identifier despite they are equal for many version identifiers?
>> >
>> > To add to what the others have said, the reasons that Walter is against having boolean conditions in version statements have to do with how using boolean conditions in #ifdefs in C/C++ has historically been a big source of bugs. So, disallowing it helps prevent certain classes of bugs. It's why druntime duplicates most C declarations across platforms.
>>
>> What kind of bugs are those?
>
> There are a variety of issues that come from it, and it's been discussed at length in past threads (and much better than I'll explain here, I'm sure), but the main issues stem from the fact that when you're writing code that is platform-dependent but using it on multiple platforms, it can become really easy to break stuff as the code is altered over time. e.g. you can make a change that works perfectly fine on the platform that you're developing on without realizing that it won't work on the other platforms sharing the same #ifdef block, and while you should be testing such code on all supported platforms, it often doesn't happen, and even when it does happen, it's usually much further down the line after many more changes have been made. It would be highly abnormal for someone to test what they're working on on all of the relevant platforms as they're working on it.

None of that is limited specifically to ifdefs. If you modify code not in an ifdef you can still cause bugs that only materialize on specific platforms. This is the nature of building for multiple platforms at the low level, hell you'll still have problems even in Java.

The D test suite doesn't run unit tests for every platform for all libraries. There's also debug assert statements that fail, and at least last I checked for some platforms didn't run debug builds, so the tests don't catch this. And not everyone develops for those platforms so I guess no one does a debug build on their systems either.

> It also can get really tricky to avoid subtle bugs once you start having more complex boolean expressions and/or have nested #ifdefs. That's where things tend to get _really_ bad. Another big problem comes in when you just assume that the code from one platform will work with another and alter existing #ifdefs to be used on the new platform. Suddenly code that was only supposed to be used on one platform is being used on multiple, and it can cause big problems depending on what that code actualy does and what assumptions were made when writing it. By simply following the basic idiom of
>
> version(A)
> {
> }
> else version(B)
> {
> }
> else
>     static assert(false, "Platform not supported");
>
> you avoid problems that stem from code being used an a platform that it's not intended for, and you get compilation errors if you try to use code on a platform that it wasn't made to work on yet. It can result in more code duplication than many people like, but it's ultimately less error-prone. Either way, in general, it's far better to design your code such that as little of it as possible is platform-dependent and that those parts that are are well-encapsulated.
>
> - Jonathan M Davis

Like I said in my other comment. This only works if you can assert out of it, and in C and C++ it is the same.

There's a bigger problem that still isnt solved, if you need one version statement that doesn't assert to failure. Since a typo will just evaluate to false, the version statement may never be active under any circumstance and it would be difficult to fins such a bug. For example for conguration options, there's no other versions you would put in else versions, and it isnt intended to fail if that configuration version isnt there. The version feature inherited one of C's worst characteristics of the preprocessor for ifdef.