www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static version proposal

reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
So many times did i feel the need for this feature:

// ---------- first module ----------
module first;

static version = MY_API;

/*
 * My API implementation.
 */

// ---------- second module ----------
module second;

import first;

version(MY_API)
{
    // My API usage.
}

The behavior is exactly the same as with -version=MY_API passed to command
prompt.

This doesn't look like a difficult feature to implement, and AFAIK a very
useful one (especially when binding C libraries, which define compile-time
version information).
Sep 23 2011
next sibling parent reply Trass3r <un known.com> writes:
Yep, I'd also like defined versions to be global, but the problem is this  
introduces an order-of-evaluation issue.
What if module second is processed before module one?
Also what if you compile each module separately with -c?
Sep 23 2011
parent Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
The same way C/C++ does it: put it into a single .di file and import it from
both
implementation and client code.
Sep 23 2011
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
This is the way to do it in D:

// ---------- first module ----------
module first;

enum USE_MY_API = true;

/*
 * My API implementation.
 */

// ---------- second module ----------
module second;

import first;

static if (USE_MY_API)
{
    // My API usage.
}

One idiom used in C/C++ is
#if API_VER >= 0xABCD
    ....
#end if
Which naturally maps to static if, which can refer to symbols in other 
modules. 
Sep 23 2011
next sibling parent reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Not exactly.
You'll also need to include code, which checks if the symbol API_VER is defined
before checking it's value. This will make the code bloated. One way to do it is
to define a template which takes the symbol in the form of a string, but that
would look very ugly.
Sep 23 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Gor F. Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:j5i2kv$2abh$1 digitalmars.com...
 Not exactly.
 You'll also need to include code, which checks if the symbol API_VER is 
 defined
 before checking it's value. This will make the code bloated. One way to do 
 it is
 to define a template which takes the symbol in the form of a string, but 
 that
 would look very ugly.

Why would you do that? You'll get an error if it's undefined, just like you would with #if in c/c++. If you wanted to use existance of a symbol instead of an enum's value, static if(is(typeof())) should do the job. Essentially, static if can already do what you're asking for, and is much more flexible.
Sep 23 2011
next sibling parent reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I suggest to rewrite the version functionality as follows.
Replace all existing functionality regarding version with a single compile-time
built-in construct (much like the `is` expression)

version(/* boolean expression */)

, which will returns true if all symbols withing the expression are defined
(including identifiers) and the expression yields true.

then, the process of version tracking will look like this:

enum MY_API = true;
enum MY_API_VERSION = 4;

static if(version(MY_API) && version(MY_API_VERSION >= 2))
{
   // ...
   // Note, that if either MY_API or MY_API_VERSION is not defined, the static
if's expression will be false.
}
Sep 23 2011
parent reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Well, i know, that it breaks code, so i intended it for D3.
About enums:
the version keyword can also be made a storage class for global compile-time
declarations to distinguish version identifiers with all other identifiers.
Sep 23 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
I hope there's no D3 for a very long time. Maybe 2020.
Sep 23 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:j5iac7$2ole$1 digitalmars.com...
I hope there's no D3 for a very long time. Maybe 2020.

I completely agree.
Sep 23 2011
parent reply Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Why don't you want D to have a backwards compatibility breaking release?
D2 got here, but D1 is still out there and gets it's occasional bug-fixes.

Having a backwards compatibility breaking release is a good way to fix mistakes,
made in the past. Not doing so leads to overly complicated and unintuitive
language like C++, where new functionality is crammed in with sacrifices to
intuitiveness.
Sep 23 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Gor F. Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:j5ibrn$2rn8$1 digitalmars.com...
 Why don't you want D to have a backwards compatibility breaking release?
 D2 got here, but D1 is still out there and gets it's occasional bug-fixes.

 Having a backwards compatibility breaking release is a good way to fix 
 mistakes,
 made in the past. Not doing so leads to overly complicated and unintuitive
 language like C++, where new functionality is crammed in with sacrifices 
 to
 intuitiveness.

Basically, because D2 is not ready to be left behind yet. There are a huge number of compiler and library bugs to be fixed, hundreds of rough corners to be polished, and huge gaps in the toolchain to be fixed. To fork D again before these issues are better resolved would be catastrophic.
Sep 23 2011
parent Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
oh, you mean the timing. I completely agree. D2 is far from being ready to let
go.
When i said D3, i meant in a galaxy far far away, where there's nothing left to
do
for D2. :-)
Sep 23 2011
prev sibling parent Adam Ruppe <destructionator gmail.com> writes:
There's several reasons backward compatibility is important:

1) Breaking it annoys me. There's still stuff I like for new features,
   so I'm not at the point where I'll never update again yet, but I
   don't want my code to break more. Especially if non-trivial.

2) It splits people. Suppose you grab a lib and it uses D3 features.
   If you're on D2, you can't touch it.

3) It gives a perception of instability. There's already enough
   complaints on this about D1 and D2.

With the costs, the benefit has to be huge to break compatibility.
Sep 23 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/23/11 10:59, Adam Ruppe wrote:
 I hope there's no D3 for a very long time. Maybe 2020.

There won't. D2 is our flagship. Andrei
Sep 23 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:j5iac7$2ole$1 digitalmars.com...
I hope there's no D3 for a very long time. Maybe 2020.

I still hope there is one at some not-too-distant point, though. The whole version system really does need an overhaul. One of the big things, if not the key one, is that basing it on "symbol defined" vs "symbol not defined" (rather than a compile-time bool) is far too problematic. There's been discussion and effort before (that I was heavily involved in) about trying to made a proper version system as a D2 library. There were some real clever strategies people worked out for certain aspects of it, but it ultimately ended up being intractable in D2.
Sep 23 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
 "Adam Ruppe" <destructionator gmail.com> wrote in message
 news:j5iac7$2ole$1 digitalmars.com...
 
I hope there's no D3 for a very long time. Maybe 2020.

I still hope there is one at some not-too-distant point, though. The whole version system really does need an overhaul. One of the big things, if not the key one, is that basing it on "symbol defined" vs "symbol not defined" (rather than a compile-time bool) is far too problematic.

That's by design. That's the way that Walter wants it. I wouldn't expect that to change in any future version of D unless you can come up with a really good argument to change Walter's mind or someone else takes over as the benevolent dictator at some point. - Jonathan M Davis
Sep 23 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.96.1316813793.26225.digitalmars-d puremagic.com...
 On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
 "Adam Ruppe" <destructionator gmail.com> wrote in message
 news:j5iac7$2ole$1 digitalmars.com...

I hope there's no D3 for a very long time. Maybe 2020.

I still hope there is one at some not-too-distant point, though. The whole version system really does need an overhaul. One of the big things, if not the key one, is that basing it on "symbol defined" vs "symbol not defined" (rather than a compile-time bool) is far too problematic.

That's by design. That's the way that Walter wants it. I wouldn't expect that to change in any future version of D unless you can come up with a really good argument to change Walter's mind or someone else takes over as the benevolent dictator at some point.

Really? I had no idea. What's the reasoning? (I honestly can't imagine anything.) One big problem with it, off the top of my head, is that there's zero safety from mistyping: // Crap, this should be FrizzBang: version(Fizzbang) {...} else {...} And that's silently accepted and results in the wrong code. Crap, this is the whole damn reason we have variable declarations in the first place. I seem to remember there being another issue or two, but I don't recall offhand what.
Sep 23 2011
prev sibling parent Gor F. Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
because version = identifier is only local to a module.
because version can be either an identifier or an integer, whereas the version
tagged variable can be anything (string, for example).
Sep 23 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2011 7:35 AM, Trass3r wrote:
 Which again raises the question why we have version at all.

They're meant for a more global view of generating different versions from the same source code.
Sep 23 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2011 1:09 PM, Jonathan M Davis wrote:
 Yes, we technically _could_ get rid of version and do it all with static ifs,
 but it wouldn't be as clean IMHO.

Right. It's the same reason for the existence of the debug conditionals. Such could be done with version or with static if, but experience with C is that every group invents their own convention for doing conditional debug code, all incompatible. Having it wired in the language tends to standardize it and make it interoperable.
Sep 23 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 If you wanted to use existance of a symbol instead of an enum's value,
 static if(is(typeof())) should do the job.
 Essentially, static if can already do what you're asking for, and is much
 more flexible.

Which again raises the question why we have version at all. I know it has its very own namespace but you could also let static if have access to that and simply make undefined versions evaluate to false.
Sep 23 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, September 23, 2011 12:59:20 Walter Bright wrote:
 On 9/23/2011 7:35 AM, Trass3r wrote:
 Which again raises the question why we have version at all.

They're meant for a more global view of generating different versions from the same source code.

Not to mention that version blocks be affected by compiler flags (unlike static if). Probably the thing that I like most about them though is that It's much nicer to split out OS differences with explicit version blocks than having them be just another set static ifs. Yes, we technically _could_ get rid of version and do it all with static ifs, but it wouldn't be as clean IMHO. - Jonathan M Davis
Sep 23 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 23.09.2011, 17:14 Uhr, schrieb Gor F. Gyolchanyan  
<gor.f.gyolchanyan gmail.com>:

 I suggest to rewrite the version functionality as follows.
 Replace all existing functionality regarding version with a single  
 compile-time
 built-in construct (much like the `is` expression)

 version(/* boolean expression */)

 , which will returns true if all symbols withing the expression are  
 defined
 (including identifiers) and the expression yields true.

 then, the process of version tracking will look like this:

 enum MY_API = true;
 enum MY_API_VERSION = 4;

 static if(version(MY_API) && version(MY_API_VERSION >= 2))
 {
    // ...
    // Note, that if either MY_API or MY_API_VERSION is not defined, the  
 static
 if's expression will be false.
 }

That would unnecessarily and heavily break existing code. Also it's a good thing to get an error if you want to use enums for versioning and they don't exist (including spell check results).
Sep 23 2011
prev sibling parent Trass3r <un known.com> writes:
 About enums:
 the version keyword can also be made a storage class for global  
 compile-time
 declarations to distinguish version identifiers with all other  
 identifiers.

How would that be superior to 'version = identifier;'?
Sep 23 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, September 23, 2011 14:54 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.96.1316813793.26225.digitalmars-d puremagic.com...
 
 On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
 "Adam Ruppe" <destructionator gmail.com> wrote in message
 news:j5iac7$2ole$1 digitalmars.com...
 
I hope there's no D3 for a very long time. Maybe 2020.

I still hope there is one at some not-too-distant point, though. The whole version system really does need an overhaul. One of the big things, if not the key one, is that basing it on "symbol defined" vs "symbol not defined" (rather than a compile-time bool) is far too problematic.

That's by design. That's the way that Walter wants it. I wouldn't expect that to change in any future version of D unless you can come up with a really good argument to change Walter's mind or someone else takes over as the benevolent dictator at some point.

Really? I had no idea. What's the reasoning? (I honestly can't imagine anything.)

I believe that it comes down to complexity. In C and C++, you get stuff like #if COND1 || COND2 || (COND3 && COND4) and it can become fairly easy to screw up when you manage versions that way - especially when each of those conditions can be arbitrarily complex _and_ they can be affected in entertaining ways by whatever #includes you happen to have before them. Simply adding or removing a #include could completely change the result of such conditions (as could reordering them in some cases). By having version restricted to what's defined and having it unaffected by imports, it simplifies the situation considerably. You can still do similarly screwy stuff with static ifs, but if you're using version blocks for version stuff and static ifs for templated stuff, then the static ifs don't usually get screwy in the same way, and the overall situtation is much cleaner. - Jonathan M Davis
Sep 23 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.100.1316815714.26225.digitalmars-d puremagic.com...
 On Friday, September 23, 2011 14:54 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.96.1316813793.26225.digitalmars-d puremagic.com...

 On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
 "Adam Ruppe" <destructionator gmail.com> wrote in message
 news:j5iac7$2ole$1 digitalmars.com...

I hope there's no D3 for a very long time. Maybe 2020.

I still hope there is one at some not-too-distant point, though. The whole version system really does need an overhaul. One of the big things, if not the key one, is that basing it on "symbol defined" vs "symbol not defined" (rather than a compile-time bool) is far too problematic.

That's by design. That's the way that Walter wants it. I wouldn't expect that to change in any future version of D unless you can come up with a really good argument to change Walter's mind or someone else takes over as the benevolent dictator at some point.

Really? I had no idea. What's the reasoning? (I honestly can't imagine anything.)

I believe that it comes down to complexity. In C and C++, you get stuff like #if COND1 || COND2 || (COND3 && COND4) and it can become fairly easy to screw up when you manage versions that way - especially when each of those conditions can be arbitrarily complex _and_ they can be affected in entertaining ways by whatever #includes you happen to have before them. Simply adding or removing a #include could completely change the result of such conditions (as could reordering them in some cases). By having version restricted to what's defined and having it unaffected by imports, it simplifies the situation considerably.

But version is *not* restricted to what's defined. It *also* deals with what's *not* defined. That's the main problem I'm talking about. If Walter wants to limit the logic operations and import implications, none of that necessitates that the version identifiers be based on "defined vs undefined". What I mean is this: Using an undefined version identifier should be an error: version(ThisIsNeverDeclaredAnywhere) {} else {} That is currently accepted, but it should be a compile-time error. If you want that to work, you should be forced to do one of the following: // A: version ThisIsDeclared = true; version(ThisIsDeclared) {} else {} // B: version ThisIsDeclared = false; version(ThisIsDeclared) {} else {} // C: version(ThisIsDeclared) {} else {}
dmd foo.d -version:ThisIsDeclared

// D: version(ThisIsDeclared) {} else {}
dmd foo.d -version:ThisIsDeclared=false  # or 
maybe -versionoff:ThisIsDeclared

Obviously you wouldn't need to (or be allowed to) declare any of the built-in version identifiers like Windows. They would be always be implicity declared and set to either true or false.
Sep 23 2011
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j5j1bh$14oc$1 digitalmars.com...
 // D:
 version(ThisIsDeclared) {} else {}
dmd foo.d -version:ThisIsDeclared=false  # or 
maybe -versionoff:ThisIsDeclared


Heh, the stupid email/ng system (or client or whatever) tried to "fix" that "quote" by adding a ">" before "maybe". Stoopid compooters.
Sep 23 2011