Frits van Bommel wrote:
> grauzone wrote:
>> Some severe disadvantages of version():
>> 1. They can't contain expressions (like "version(linux && mac)").
> 
> Unless Apple has plans to s/BSD/Linux/ in MacOS that I'm not aware of, version(linux || mac) would probably be more useful...
> 
> 
> Allowing boolean expressions (using only version identifiers) in version() would be a very welcome feature.
> 
> I'm not sure about the rest of your post though.

Well, my argument is that CTFE already provides all version features and even more. version is redundant, and even dangerous, because it can't catch typos in version identifiers.

Actually, C/C++ has something similar: #if (is similar to static if) versus #ifdef (is similar to version). ffmpeg recently switched from using #ifdef to #if.

On Tue, 10 Feb 2009 13:08:03 +0100, Don wrote:

> A&&B is not so terrible, since you can do it by nesting, as above. The big problem is A || B. It creates a mess.

version(A) version = AorB;
version(B) version = AorB;
version(AorB) {
  . . .
}

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Derek Parnell wrote:
> On Tue, 10 Feb 2009 13:08:03 +0100, Don wrote:
> 
>> A&&B is not so terrible, since you can do it by nesting, as above.
>> The big problem is A || B. It creates a mess.
> 
> version(A) version = AorB;
> version(B) version = AorB;
> version(AorB) {
>   . . .
> }
> 
Yes. And that sucks, because you've got the version statement in two places. And you've had to create an essentially meaningless temporary. [1] Then when you have a more complex expression, especially where A and B appear more than once, it gets disgusting.


[1] I know Walter's idea is that you create meaningful identifiers, but in practice this kind of versioning can be a workaround. EG B is "everything except WindowsME".

bobef wrote:
> I was thinking... what is the point of version() ? It is so inflexible. There is no even version(!...). Why not "static if(version(DMD))" or static if(is(version == DMD))?
> 
> Regards,
> bobef

version() is MUCH older than static if. It dates from a very early time in D's history.
I requested module-scope static if, and Walter said "that's probably almost impossible to implement", but he did it anyway <g>.

Don:
> I requested module-scope static if, and Walter said "that's probably almost impossible to implement", but he did it anyway <g>.

Walter does almost the impossible, sometimes. I'll have to remember this :-)

Bye,
bearophile

On Tue, 10 Feb 2009 17:14:00 +0300, Don <nospam@nospam.com> wrote:

> Derek Parnell wrote:
>> On Tue, 10 Feb 2009 13:08:03 +0100, Don wrote:
>>
>>> A&&B is not so terrible, since you can do it by nesting, as above.
>>> The big problem is A || B. It creates a mess.
>>  version(A) version = AorB;
>> version(B) version = AorB;
>> version(AorB) {
>>   . . .
>> }
>>
> Yes. And that sucks, because you've got the version statement in two places. And you've had to create an essentially meaningless temporary. [1] Then when you have a more complex expression, especially where A and B appear more than once, it gets disgusting.
>
>
> [1] I know Walter's idea is that you create meaningful identifiers, but in practice this kind of versioning can be a workaround. EG B is "everything except WindowsME".

Version has so many shortcomings that it should definitely be redesigned.

My biggest complaint is that code inside version () {} block should be semantically correct. It creates many obstacles and disallows good use-cases:
- you cannot mix D1, D2 and (in future) D3 in a single source code file without helf of mixins.
- you cannot mix asm for different platforms in one source code file (because DMD doesn't understand ARM assembly, for instance)
- etc

Other use-case I came across recently reading .NET Framework source code:

class String :
   IFoo,
   IBar,
   IBaz,
#if SUPPORT_GENERICS
   IComparable<Foo>,
#endif
   IWhee
{
   // *very* large amount of code
}

How would you port it to D without code duplication and meaningless intermediate classes?

bearophile wrote:
> Don:
>> I requested module-scope static if, and Walter said "that's probably almost impossible to implement", but he did it anyway <g>.
> 
> Walter does almost the impossible, sometimes. I'll have to remember this :-)
> 
> Bye,
> bearophile

The traditional way to get an engineer to do something, is to tell him you believe it's impossible. Works very well with Walter.
Also Walter tends not to promise to do something, unless he's already finished it <g>.

Denis Koroskin wrote:
> [snip]
> 
> Other use-case I came across recently reading .NET Framework source code:
> 
> class String :
>    IFoo,
>    IBar,
>    IBaz,
> #if SUPPORT_GENERICS
>    IComparable<Foo>,
> #endif
>    IWhee
> {
>    // *very* large amount of code
> }
> 
> How would you port it to D without code duplication and meaningless intermediate classes?

I think I once tried something where I was building a list of interface types as a tuple, then tried this:

class Foo : InterfaceTuple { ... }

Didn't work, though.

  -- Daniel

Denis Koroskin wrote:
> On Tue, 10 Feb 2009 17:14:00 +0300, Don <nospam@nospam.com> wrote:
> 
>> Derek Parnell wrote:
>>> On Tue, 10 Feb 2009 13:08:03 +0100, Don wrote:
>>>
>>>> A&&B is not so terrible, since you can do it by nesting, as above.
>>>> The big problem is A || B. It creates a mess.
>>>  version(A) version = AorB;
>>> version(B) version = AorB;
>>> version(AorB) {
>>>   . . .
>>> }
>>>
>> Yes. And that sucks, because you've got the version statement in two places. And you've had to create an essentially meaningless temporary. [1] Then when you have a more complex expression, especially where A and B appear more than once, it gets disgusting.
>>
>>
>> [1] I know Walter's idea is that you create meaningful identifiers, but in practice this kind of versioning can be a workaround. EG B is "everything except WindowsME".
> 
> Version has so many shortcomings that it should definitely be redesigned.
> 
> My biggest complaint is that code inside version () {} block should be semantically correct.

Just syntactically correct.

"grauzone" <none@example.net> wrote in message news:gmrpj5$1hea$1@digitalmars.com...
> bobef wrote:
>> I was thinking... what is the point of version() ? It is so inflexible. There is no even version(!...). Why not "static if(version(DMD))" or static if(is(version == DMD))?
>>
>> Regards,
>> bobef
>
> One of my pet peeves.
>
> The only advantages of version() over static if() are:
> 1. You can pass version flags as command line parameters
> 2. It is shorter.
>
> Some severe disadvantages of version():
> 1. They can't contain expressions (like "version(linux && mac)").
> 2. Typos are not catched! "version(linxu)" will just silently compile.
>
> Proposal to solve these problems:
>
> Remove "version()" and replace it by "static if()" (actually, it would make sense to turn version into an alias for static if). Introduce const declarations, which get their value from commandline:
>
> //command line for dmd to set the constant cLinux
>
> dmd -version cLinux=true
>
> //define a const variable, whose value is taken from the commandline //they always need to be declared, the compiler shouldn't just //arbitrarily introduce new symbols into the modules' scope! //(exact syntax needs to be discussed)
>
> const bool cLinux = $cmdarg;
>
> //instead of version(linux)
> //unlike version, arbitrary expressions are allowed
>
> static if(cLinux) {
> //Linux code goes here
> }
>
> static if(cLinxu) { //oops, typo, the compiler will loudly complain!
>
> As an additional feature, you could allow passing of additional data types instead of only bool. Strings, for example.
>
> Unlike version(), cLinux always needs to be defined on the command line. I don't consider this a disadvantage.
>
> I'd also leave debug() as it is.


I wholeheartedly agree with this 100%. I'd also have to agree with Denis's point about the semantic/syntactic restrictions:

"Denis Koroskin" <2korden@gmail.com> wrote in message news:op.uo433jipo7cclz@proton.creatstudio.intranet...
> My biggest complaint is that code inside version () {} block should be
> semantically correct. It creates many obstacles and disallows good
> use-cases:
> - you cannot mix D1, D2 and (in future) D3 in a single source code file
> without helf of mixins.
> - you cannot mix asm for different platforms in one source code file
> (because DMD doesn't understand ARM assembly, for instance)
> - etc