www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - version: multiple conditions

reply bitwise <bitwise.pvt gmail.com> writes:
What is the rationale for not allowing multiple version conditions?

Example:

version(iOS || Android) {
     pthread_create(...)
}
else version(Win32) {
     CreateThread(...)
}

I wasn't able to find the conversations on this.

I heard rumors in DLearn that Walter was against this, but I'm wondering  
if the sentiment has changed at this point. Is there is any wiggle room  
for at least adding "||" so that code can be shared between platforms?


This is trivial to do in C, C++, and even C#:

#if OS_IOS || OS_ANDROID
    ...
#elif OS_WINDOWS

#endif


In Rust, there is attributes for this:

#[cfg(any(not(unix), all(target_os="macos", target_arch = "powerpc")))]
void something() {

}

I haven't yet seen a solution in D that justifies not having this feature.


Thanks,
   Bit
Jun 13 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 13 June 2015 at 20:57:14 UTC, bitwise wrote:
 What is the rationale for not allowing multiple version 
 conditions?

 Example:

 version(iOS || Android) {
     pthread_create(...)
 }
 else version(Win32) {
     CreateThread(...)
 }

 I wasn't able to find the conversations on this.

 I heard rumors in DLearn that Walter was against this, but I'm 
 wondering if the sentiment has changed at this point. Is there 
 is any wiggle room for at least adding "||" so that code can be 
 shared between platforms?


 This is trivial to do in C, C++, and even C#:

 #if OS_IOS || OS_ANDROID
    ...
 #elif OS_WINDOWS

 #endif


 In Rust, there is attributes for this:

 #[cfg(any(not(unix), all(target_os="macos", target_arch = 
 "powerpc")))]
 void something() {

 }

 I haven't yet seen a solution in D that justifies not having 
 this feature.


 Thanks,
   Bit
iirc this falls under the "walter dislikes it so we won't have it" category.
Jun 13 2015
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sat, 13 Jun 2015 17:16:04 -0400, weaselcat <weaselcat gmail.com> wrote:>
 iirc this falls under the "walter dislikes it so we won't have it"  
 category.
As Andrei said at DConf though, consensus requires at least 3 people ;) Bit
Jun 13 2015
parent reply "Xiaoxi" <xiaoxi 163.com> writes:
On Saturday, 13 June 2015 at 21:19:28 UTC, bitwise wrote:
 On Sat, 13 Jun 2015 17:16:04 -0400, weaselcat 
 <weaselcat gmail.com> wrote:>
 iirc this falls under the "walter dislikes it so we won't have 
 it" category.
As Andrei said at DConf though, consensus requires at least 3 people ;) Bit
The current design encourages using more finegrained features instead of the more blunt Os level versions. version(iOS) { version = pthread;} version(Android) { version = pthread;} In the rest of the file simply check for pthread instead of OS.
Jun 13 2015
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sat, 13 Jun 2015 17:29:17 -0400, Xiaoxi <xiaoxi 163.com> wrote:

 On Saturday, 13 June 2015 at 21:19:28 UTC, bitwise wrote:
 On Sat, 13 Jun 2015 17:16:04 -0400, weaselcat <weaselcat gmail.com>  
 wrote:>
 iirc this falls under the "walter dislikes it so we won't have it"  
 category.
As Andrei said at DConf though, consensus requires at least 3 people ;) Bit
The current design encourages using more finegrained features instead of the more blunt Os level versions. version(iOS) { version = pthread;} version(Android) { version = pthread;} In the rest of the file simply check for pthread instead of OS.
That _sounds_ nice, but consider this: version (linux) { import core.sys.linux.dlfcn; } else version (FreeBSD) { import core.sys.freebsd.dlfcn; } version(linux || FreeBSD) { dlopen(...) } I shouldn't have to add another version just for that last dlopen block. It's not "finegrained" control, it's cruft. Bit
Jun 13 2015
next sibling parent "Etienne Cimon" <etcimon gmail.com> writes:
On Saturday, 13 June 2015 at 21:51:43 UTC, bitwise wrote:
 I shouldn't have to add another version just for that last 
 dlopen block. It's not "finegrained" control, it's cruft.

     Bit
It works with constants definition files. https://github.com/etcimon/botan/blob/master/source/botan/constants.d The mono-d IDE doesn't always like it but it's the best I've got.
Jun 13 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Saturday, 13 June 2015 at 21:51:43 UTC, bitwise wrote:
 On Sat, 13 Jun 2015 17:29:17 -0400, Xiaoxi <xiaoxi 163.com> 
 wrote:

 On Saturday, 13 June 2015 at 21:19:28 UTC, bitwise wrote:
 On Sat, 13 Jun 2015 17:16:04 -0400, weaselcat 
 <weaselcat gmail.com> wrote:>
 iirc this falls under the "walter dislikes it so we won't 
 have it" category.
As Andrei said at DConf though, consensus requires at least 3 people ;) Bit
The current design encourages using more finegrained features instead of the more blunt Os level versions. version(iOS) { version = pthread;} version(Android) { version = pthread;} In the rest of the file simply check for pthread instead of OS.
That _sounds_ nice, but consider this: version (linux) { import core.sys.linux.dlfcn;
version = use_dlopen;
 }
 else version (FreeBSD) {
     import core.sys.freebsd.dlfcn;
version = use_dlopen;
 }

 version(linux || FreeBSD) {
//version(linux || FreeBSD) { version(use_dlopen) {
     dlopen(...)
 }

 I shouldn't have to add another version just for that last 
 dlopen block. It's not "finegrained" control, it's cruft.
It does require more definitions, but it's worth it. A simple example like yours may seem excusable, but there's no way to limit such logic to just simple instances. Walter is coming from long experience with this, and even with my limited experience with such logic, I'm grateful for it, as dealing with more complex versions of such logic is a royal PITA.
Jun 14 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 14 Jun 2015 10:35:30 +0000, Joakim wrote:

 It does require more definitions, but it's worth it.  A simple example
 like yours may seem excusable, but there's no way to limit such logic to
 just simple instances.  Walter is coming from long experience with this,
 and even with my limited experience with such logic, I'm grateful for
 it, as dealing with more complex versions of such logic is a royal PITA.
honestly, if i'll want to have a limited language, i'll take Go. removing=20 a power only 'cause it can be abused is not in a "spirit of D", at least=20 as i see it. templates can be enormously abused, but noone claims that=20 they should be removed, as code without templates sometimes easier to=20 follow, and abusing templates can be a PITA.=
Jun 14 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 14 June 2015 at 11:03:49 UTC, ketmar wrote:
 On Sun, 14 Jun 2015 10:35:30 +0000, Joakim wrote:

 It does require more definitions, but it's worth it.  A simple 
 example
 like yours may seem excusable, but there's no way to limit 
 such logic to
 just simple instances.  Walter is coming from long experience 
 with this,
 and even with my limited experience with such logic, I'm 
 grateful for
 it, as dealing with more complex versions of such logic is a 
 royal PITA.
honestly, if i'll want to have a limited language, i'll take Go. removing a power only 'cause it can be abused is not in a "spirit of D", at least as i see it. templates can be enormously abused, but noone claims that they should be removed, as code without templates sometimes easier to follow, and abusing templates can be a PITA.
Walter explained his thinking behind this decision in five comments on this PR: https://github.com/D-Programming-Language/dlang.org/pull/243#issuecomment-12883555 I agree with him. You shouldn't be using such logic at the point the code is inserted or elided. It can get very confusing as you layer on logic and is extremely brittle for anything approaching even a medium-sized codebase. You may be able to get away with it for a small codebase, but then you really can't complain about repetition, because there isn't much code in the first place. ;) Of course, there's always a way out: use static if like Etienne did in his linked file. But that's not a good practice and it's good that Walter is to discouraging it.
Jun 14 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 14 Jun 2015 14:26:25 +0000, Joakim wrote:

 Walter explained his thinking behind this decision in five comments on
 this PR:
exactly what i told: "I don't like it, so abandon all hope".=
Jun 14 2015
prev sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Sun, 14 Jun 2015 10:26:25 -0400, Joakim <dlang joakim.fea.st> wrote:

 Walter explained his thinking behind this decision in five comments on  
 this PR:
Thanks for the link ;) Bit
Jun 14 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2015 4:03 AM, ketmar wrote:
 honestly, if i'll want to have a limited language, i'll take Go.
Go doesn't have conditional compilation.
 removing a power only 'cause it can be abused is not in a "spirit of D",
Actually, D does quite a bit of that. For example, it deliberately does not allow > to be overloaded separately from <. It does not allow multiple inheritance. It does not allow structs to have virtual functions. (All of these deliberate limitations have had their proponents.)
Jun 16 2015
next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Tuesday, 16 June 2015 at 10:05:05 UTC, Walter Bright wrote:
 It does not allow multiple inheritance.
I have often heard from Lisp programmers that the rejection of multiple inheritance is a weakness. They believe that it's well implemented in Lisp, and developers of other languages can not solve the problem of the diamond.
Jun 16 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 16 June 2015 at 10:39:48 UTC, Dennis Ritchie wrote:
 On Tuesday, 16 June 2015 at 10:05:05 UTC, Walter Bright wrote:
 It does not allow multiple inheritance.
Unfortunately not true, you're adding multiple alias this…
 I have often heard from Lisp programmers that the rejection of 
 multiple inheritance is a weakness. They believe that it's well 
 implemented in Lisp, and developers of other languages can not 
 solve the problem of the diamond.
You probably refer to CLOS and not proper Lisp. C++ has multiple inheritance and "solves" it, but most C++ programmers try to avoid multiple inheritance anyway. So why would D be better with it?
Jun 16 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
On Tuesday, 16 June 2015 at 13:16:40 UTC, Ola Fosheim Grøstad 
wrote:
 Unfortunately not true, you're adding multiple alias this…
Excuse me for what I am trying to avoid overquoting :)
 You probably refer to CLOS and not proper Lisp.
CLOS was adopted as part of the standard ANSI Common Lisp. What is interesting to know ANSI Common Lisp is wrong?
 C++ has multiple inheritance and "solves" it, but most C++ 
 programmers try to avoid multiple inheritance anyway. So why 
 would D be better with it?
In different languages rhombus problem is solved in different ways. And C++ is not the best case in point, where the problem is solved well. Of course, most of the C++-programmers avoid multiple inheritance, but the other part, which uses it at least a little, what a tie that does not use it. D - this is not the language of minimalist (for example, Go) :) We had to implement multiple inheritance, without relying on C++. IMO.
Jun 16 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-16 12:05, Walter Bright wrote:

 Actually, D does quite a bit of that. For example, it deliberately does
 not allow > to be overloaded separately from <.
Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593 -- /Jacob Carlborg
Jun 16 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote:
 On 2015-06-16 12:05, Walter Bright wrote:

 Actually, D does quite a bit of that. For example, it 
 deliberately does
 not allow > to be overloaded separately from <.
Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593
Sounds like it's preventing an abuse of operator overloading to me... :) - Jonathan M Davis
Jun 16 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 16 June 2015 at 20:36:20 UTC, Jonathan M Davis wrote:
 On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote:
 On 2015-06-16 12:05, Walter Bright wrote:

 Actually, D does quite a bit of that. For example, it 
 deliberately does
 not allow > to be overloaded separately from <.
Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593
Sounds like it's preventing an abuse of operator overloading to me... :) - Jonathan M Davis
You call it abuse, I call it developer freedom.
Jun 16 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2015 1:46 PM, rsw0x wrote:
 You call it abuse, I call it developer freedom.
#define BEGIN { #define END } Freedom! Freedom! Freedom! https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
Jun 16 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
 On 6/16/2015 1:46 PM, rsw0x wrote:
 You call it abuse, I call it developer freedom.
#define BEGIN { #define END } Freedom! Freedom! Freedom! https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN ah, now we're getting somewhere.
Jun 16 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 16 June 2015 at 21:09:40 UTC, rsw0x wrote:
 On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
 On 6/16/2015 1:46 PM, rsw0x wrote:
 You call it abuse, I call it developer freedom.
#define BEGIN { #define END } Freedom! Freedom! Freedom! https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN ah, now we're getting somewhere.
wow, that got mangled by my touchscreen :(
Jun 16 2015
parent "anonymous" <anonymous anonymous.com> writes:
On Tuesday, 16 June 2015 at 21:10:50 UTC, rsw0x wrote:
 On Tuesday, 16 June 2015 at 21:09:40 UTC, rsw0x wrote:
 On Tuesday, 16 June 2015 at 20:59:35 UTC, Walter Bright wrote:
 On 6/16/2015 1:46 PM, rsw0x wrote:
 You call it abuse, I call it developer freedom.
#define BEGIN { #define END } Freedom! Freedom! Freedom! https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
#define PROGRAM main() BEGIN ah, now we're getting somewhere.
wow, that got mangled by my touchscreen :(
https://gist.github.com/jcromartie/238308
Jun 16 2015
prev sibling next sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Tue, 16 Jun 2015 16:59:36 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 6/16/2015 1:46 PM, rsw0x wrote:
 You call it abuse, I call it developer freedom.
#define BEGIN { #define END } Freedom! Freedom! Freedom! https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
I take it I should just skip my next suggestion ;) Bit
Jun 16 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-06-16 22:59, Walter Bright wrote:

 #define BEGIN {
 #define END }

 Freedom! Freedom! Freedom!

 https://www.youtube.com/watch?feature=player_detailpage&v=lEOOZDbMrgE#t=163
And the current approach to operator overload is soooo much better, preventing all abuse: struct Int { int a; int opBinary(string s)(Int rhs) if (s == "+") { return a - rhs.a; } } -- /Jacob Carlborg
Jun 16 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2015 1:36 PM, Jonathan M Davis wrote:
 On Tuesday, 16 June 2015 at 19:55:21 UTC, Jacob Carlborg wrote:
 On 2015-06-16 12:05, Walter Bright wrote:

 Actually, D does quite a bit of that. For example, it deliberately does
 not allow > to be overloaded separately from <.
Which has its own limitations [1]. [1] https://issues.dlang.org/show_bug.cgi?id=14593
Sounds like it's preventing an abuse of operator overloading to me... :)
Yup, it's doing its job! Use of expression templates in C++ to implement DSLs is probably some of the most awful code ever conceived.
Jun 16 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 16 June 2015 at 20:57:03 UTC, Walter Bright wrote:
 Use of expression templates in C++ to implement DSLs is 
 probably some of the most awful code ever conceived.
Whereas string mixins allow us to do all kinds of crazy stuff with DSLs if you want to - but they're clearly confined in strings where you're not going to mistake them for normal D code. It's _very_ cool how Pegged is able to take a grammar in normal, PEG format, and generate a parser from it. But attempting anything like that with expression templates would have been horrible. - Jonathan M Davis
Jun 16 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 17 June 2015 at 05:09:54 UTC, Jonathan M Davis 
wrote:
 On Tuesday, 16 June 2015 at 20:57:03 UTC, Walter Bright wrote:
 Use of expression templates in C++ to implement DSLs is 
 probably some of the most awful code ever conceived.
A lot of things in C++ are ill-conceived, but templates were not designed to do things like that. So the language does not endorse it. Mal-features like string-mixins and multiple-alias-this endorse writing ugly code. Those are deliberate features. And it is actually worse than Javascript...
 Whereas string mixins allow us to do all kinds of crazy stuff 
 with DSLs if you want to - but they're clearly confined in 
 strings where you're not going to mistake them for normal D 
 code. It's _very_ cool how Pegged is able to take a grammar in 
 normal, PEG format, and generate a parser from it. But 
 attempting anything like that with expression templates would 
 have been horrible.
I've noticed that a key difference between D and Javascript programmers is that the latter group through-and-through acknowledge that eval() is a problematic feature.
Jun 16 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-16 22:36, Jonathan M Davis wrote:

 Sounds like it's preventing an abuse of operator overloading to me... :)
Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :) -- /Jacob Carlborg
Jun 16 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
 Sounds like it's preventing a perfectly good use case. Or do 
 you prefer AST macros instead :)
Given the direction D2 has taken since D1, I'd say that I'm starting to agree with you that powerful symbolic programming would be the better deal overall. But it would take a major restructuring: 1. a simpler more orthogonal core language to cut down on the special casing when doing AST manipulations 2. a clean separation between library and application code (that way you can limit AST hacks to libraries tie library versions to language versions. So it won't happen… since you would then have essentially need a new language?
Jun 17 2015
parent Jacob Carlborg <doob me.com> writes:
On 17/06/15 10:03, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com> wrote:

 Given the direction D2 has taken since D1, I'd say that I'm starting to
 agree with you that powerful symbolic programming would be the better
 deal overall.

 But it would take a major restructuring:

 1. a simpler more orthogonal core language to cut down on the special
 casing when doing AST manipulations

 2. a clean separation between library and application code (that way you
 can limit AST hacks to libraries tie library versions to language versions.

 So it won't happen… since you would then have essentially need a new
 language?
It will most likely not happen. Although, I guess you could just slap it on, but it would not be an ideal solution. -- /Jacob Carlborg
Jun 18 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
 On 2015-06-16 22:36, Jonathan M Davis wrote:

 Sounds like it's preventing an abuse of operator overloading 
 to me... :)
Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :)
I prefer that operators actually do what they're supposed to do per how they work with the built-in types and that they not be redefined to do something else. An operator which is overloaded specifically do something other than what occurs with the built-in types is just begging for problems. Sure, we can't prevent all operator overloading abuses, and they can be misimplemented just like any other function, but the whole point of having operator overloading is to make it so that user-defined types can look and operate like built-in types, not to invent new syntax, and I think that inventing new syntax via operator overloading is a _very_ clear abuse of it. And I really don't think that folks should be trying to add syntax to the language for DSLs or anything of the sort, and I'm very glad that D prevents that in many cases while still allowing us to have useful features such as operator overloading. - Jonathan M Davis
Jun 17 2015
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/17/2015 02:28 PM, Jonathan M Davis wrote:
 On Wednesday, 17 June 2015 at 06:23:15 UTC, Jacob Carlborg wrote:
 On 2015-06-16 22:36, Jonathan M Davis wrote:

 Sounds like it's preventing an abuse of operator overloading to me... :)
Sounds like it's preventing a perfectly good use case. Or do you prefer AST macros instead :)
I prefer that operators actually do what they're supposed to do per how they work with the built-in types and that they not be redefined to do something else. An operator which is overloaded specifically do something other than what occurs with the built-in types is just begging for problems. Sure, we can't prevent all operator overloading abuses, and they can be misimplemented just like any other function, but the whole point of having operator overloading is to make it so that user-defined types can look and operate like built-in types, not to invent new syntax, and I think that inventing new syntax via operator overloading is a _very_ clear abuse of it. And I really don't think that folks should be trying to add syntax to the language for DSLs or anything of the sort, and I'm very glad that D prevents that in many cases while still allowing us to have useful features such as operator overloading. - Jonathan M Davis
FWIW, the use case presented was roughly to make the database look and operate like built-in arrays.
Jun 17 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 16 Jun 2015 03:05:06 -0700, Walter Bright wrote:

 On 6/14/2015 4:03 AM, ketmar wrote:
 honestly, if i'll want to have a limited language, i'll take Go.
=20 Go doesn't have conditional compilation.
you got it!
  > removing a power only 'cause it can be abused is not in a "spirit of
  > D",
=20
 Actually, D does quite a bit of that. For example, it deliberately does
 not allow > to be overloaded separately from <. It does not allow
 multiple inheritance. It does not allow structs to have virtual
 functions.
=20
 (All of these deliberate limitations have had their proponents.)
and you know what? people constantly trying to "fix" that. what is funny=20 is that sometimes ugly kludges are even considered for inclusion into=20 language ("multiple `alias this`, i'm looking at you! ah, and `alias=20 this` for that matter). i also wonder why we have `opCmp` and `opEquals` instead of `opEquals`=20 and `opLess` only. having so powerful `opCmp` surely opens alot way to=20 abuse it.=
Jun 17 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 17 June 2015 at 17:18:42 UTC, ketmar wrote:
 On Tue, 16 Jun 2015 03:05:06 -0700, Walter Bright wrote:

 On 6/14/2015 4:03 AM, ketmar wrote:
 honestly, if i'll want to have a limited language, i'll take 
 Go.
Go doesn't have conditional compilation.
you got it!
  > removing a power only 'cause it can be abused is not in a 
 "spirit of
  > D",
 
 Actually, D does quite a bit of that. For example, it 
 deliberately does not allow > to be overloaded separately from 
 <. It does not allow multiple inheritance. It does not allow 
 structs to have virtual functions.
 
 (All of these deliberate limitations have had their 
 proponents.)
and you know what? people constantly trying to "fix" that. what is funny is that sometimes ugly kludges are even considered for inclusion into language ("multiple `alias this`, i'm looking at you! ah, and `alias this` for that matter).
sometimes I find 'alias this' quite elegant, such as using alias this to a function. Other times I find it to be a poor hack to get around the lack of struct inheritance.
Jun 17 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 17 Jun 2015 17:25:05 +0000, weaselcat wrote:

 sometimes I find 'alias this' quite elegant, such as using alias this to
 a function. Other times I find it to be a poor hack to get around the
 lack of struct inheritance.
i agree that it has it's uses, but it's still a weird hack. and it=20 introduces subtle bugs to compiler, like bug #14653, for example. it's=20 overlooked 'cause `alias this` is so hackish...=
Jun 17 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
p.s. i.e. it boils down to simple thing: Walter don't like it. period.=20
any rationalizing of that is pointless.=
Jun 14 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote:
 p.s. i.e. it boils down to simple thing: Walter don't like it. 
 period.
 any rationalizing of that is pointless.
The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable.
Jun 14 2015
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 14 June 2015 at 11:26:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote:
 p.s. i.e. it boils down to simple thing: Walter don't like it. 
 period.
 any rationalizing of that is pointless.
The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable.
Not all of them http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/
Jun 14 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 11:33:52 UTC, Paulo Pinto wrote:
 Not all of them

 http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/
AFAIK in the discussions it becomes clear that just about everyone want the change, but some want the change to be saved for 2.0 out of SemVer principles, not because it affects actual code that is in production. I wouldn't use Rust until it hits 2.0, but then again, I also wait 1 year to install a new OS...
Jun 14 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 14 June 2015 at 11:33:52 UTC, Paulo Pinto wrote:
 On Sunday, 14 June 2015 at 11:26:23 UTC, Ola Fosheim Grøstad 
 wrote:
 On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote:
 p.s. i.e. it boils down to simple thing: Walter don't like 
 it. period.
 any rationalizing of that is pointless.
The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable.
Not all of them http://www.reddit.com/r/rust/comments/39f2t7/planned_breaking_change_in_rust_11/
not really surprising considering rust was rushed out the door, there were no breaks on that hype train.
Jun 14 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 12:06:03 UTC, weaselcat wrote:
 not really surprising considering rust was rushed out the door, 
 there were no breaks on that hype train.
I dunno if it was rushed. They have slashed the feature set quite a lot over the years. At some point it makes a lot of sense to set a fixed deadline and stick to it at the expense of expanding the feature set and strongly encouraging bug fixing. If anything the discussion around SemVer in the Rust community suggests that a lot of people there take language stability very seriously.
Jun 14 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 14 Jun 2015 11:26:21 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 I'm sure Walter will be much more open to changes if there is a proven
 demand for it
only if he like it. or at least indifferent to it. "This is true IF you are trying to use version blocks in the same way one=20 does in C. However, that is the stylistically wrong way to do it in D." that's all. it doesn't matter how loud people would complian, it's=20 "syntactically wrong". period.=
Jun 14 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 15:46:39 UTC, ketmar wrote:
 On Sun, 14 Jun 2015 11:26:21 +0000, Ola Fosheim Grøstad wrote:

 I'm sure Walter will be much more open to changes if there is 
 a proven
 demand for it
only if he like it. or at least indifferent to it. "This is true IF you are trying to use version blocks in the same way one does in C. However, that is the stylistically wrong way to do it in D." that's all. it doesn't matter how loud people would complian, it's "syntactically wrong". period.
"a proven demand" is just a kind way of describing "an emerging fork"... ;^)
Jun 14 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 14 Jun 2015 15:49:40 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Sunday, 14 June 2015 at 15:46:39 UTC, ketmar wrote:
 On Sun, 14 Jun 2015 11:26:21 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=
:
 I'm sure Walter will be much more open to changes if there is a proven
 demand for it
only if he like it. or at least indifferent to it. "This is true IF you are trying to use version blocks in the same way one does in C. However, that is the stylistically wrong way to do it in D." that's all. it doesn't matter how loud people would complian, it's "syntactically wrong". period.
=20 "a proven demand" is just a kind way of describing "an emerging fork"... =20 ;^)
any D fork is doomed to die. community is too small, there are simply not=20 enough developers to make a split. i'm doing Aliced for my own favor, yet=20 i never thought that it can be a competitor for vanilla.=
Jun 14 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
p.s. sorry, "stylistically", of course. mea maxima culpa.=
Jun 14 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Sunday, 14 June 2015 at 11:26:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 14 June 2015 at 11:05:36 UTC, ketmar wrote:
 p.s. i.e. it boils down to simple thing: Walter don't like it. 
 period.
 any rationalizing of that is pointless.
The most sensible thing to do with all these may/may not be an improvement and also the break/don't break my code issues is to create an experimental branch of DMD after the transition from C++ to D is finished. Then merge back the good stuff after several iterations of improvement. I'm sure Walter will be much more open to changes if there is a proven demand for it, e.g. if people rave about certain features in an experimental branch. Changing the main branch with "might be a little bit better" changes is a hard sell when competing languages are going stable.
Walter is _very_ firm on this issue, and I very much doubt that he will ever change his mind. He is convinced that using condition-based versioning as frequently occurs in C is almost never done correctly and that it's a horrible idea and that it's far better to separate out each version into its own version block, even if that means duplicating code. It came up again at dconf, and again, he gave his reasons and outright refused to even consider changing it. And I don't think that he's very happy that folks have started using static if blocks to get around the restrictions in version blocks (but given the general nature of static if blocks, it's not like he can stop folks). He's absolutely convinced that using conditional expressions in version blocks is a fundamentally bad design and that anyone who's doing anything like it is just begging for trouble. So, it really doesn't matter how many folks think that allowing arbitrary conditions in version blocks - or even or-ing versions in version blocks - is something that we should have. Walter is absolutely convinced that changing how version blocks in D work would be detrimental to the language, and ultimately, he's the one in charge. I think that it's pretty clear that spending any time trying to get it changed is simply a waste of your time. Language stability has nothing to do with it, and it really doesn't matter how many users want it. - Jonathan M Davis
Jun 15 2015
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 15 June 2015 at 14:51:41 UTC, Jonathan M Davis wrote:
 [...]
There's something refreshing about the simplicity of that :)
Jun 15 2015
parent bitwise <bitwise.pvt gmail.com> writes:
On Mon, 15 Jun 2015 10:58:16 -0400, John Colvin  
<john.loughran.colvin gmail.com> wrote:

 On Monday, 15 June 2015 at 14:51:41 UTC, Jonathan M Davis wrote:
 [...]
There's something refreshing about the simplicity of that :)
Faith inspiring...if He's so sure, maybe he actually does know what he's talking about ;) I haven't had this problem myself, but I looked at the source code for Boost once.... Bit
Jun 15 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2015 7:51 AM, Jonathan M Davis wrote:
 [...]
I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such. Over time, I've gotten rid of most of that stuff from the dmd source code, and the result has been quite pleasing.
Jun 16 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:mloslo$1o7v$1 digitalmars.com...

 I have yet to see a single case of "needing" boolean versions that could 
 not be refactored into something much more readable and maintainable that 
 did not use such.

 Over time, I've gotten rid of most of that stuff from the dmd source code, 
 and the result has been quite pleasing.
The numerous remaining cases in dmd are why ddmd uses static if instead of version. It's almost always easier to just use the more powerful 'static if' than to refactor the code to use D's crippled 'version'. Keeping this feature simple and limited just pushes the complexity into user code.
Jun 16 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2015 6:04 PM, Daniel Murphy wrote:
 Keeping this feature simple and limited just pushes the complexity into user
code.
I simply don't believe that. It does take some work to redesign and refactor to find a better way, but the result should not be more complicated.
Jun 16 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 16 Jun 2015 03:10:01 -0700, Walter Bright wrote:

 I have yet to see a single case of "needing" boolean versions that could
 not be refactored into something much more readable and maintainable
 that did not use such.
and i have yet to see such cases for multiplication operator. it's=20 cryptic, it's hard to read, it looks like line noise. isn't this clear=20 and readable? a =3D 5.mul(12); and now see the stupid line noise, introduced by "*": a =3D 5*12; wtf?! what is that star? some trash from modem?! surely, people can write=20 a function to do multiplication if they need it: T mul(T a, T b) { T res =3D a; foreach (_; 1..b) res +=3D a; return res; = } simle and elegant. yes, it doesn't work with floats or negative `b`, but=20 hey, it's for readability! if you want to process negative `b`, write=20 `mulneg`! so i'm sure that "*" as multiplication should be removed from the=20 language.=
Jun 17 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 17 June 2015 at 17:24:50 UTC, ketmar wrote:
 On Tue, 16 Jun 2015 03:10:01 -0700, Walter Bright wrote:

 I have yet to see a single case of "needing" boolean versions 
 that could not be refactored into something much more readable 
 and maintainable that did not use such.
and i have yet to see such cases for multiplication operator. it's cryptic, it's hard to read, it looks like line noise. isn't this clear and readable? a = 5.mul(12); and now see the stupid line noise, introduced by "*": a = 5*12;
:) Good use-cases for boolean overloads in addition to DSLs: https://en.wikipedia.org/wiki/Fuzzy_logic https://en.wikipedia.org/wiki/Three-valued_logic https://en.wikipedia.org/wiki/Four-valued_logic etc... Although I think it might be more readable to have "and", "or" etc as operators. This is actually allowed in C++: "a && b" <=> "a and b"…
Jun 18 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 18 Jun 2015 09:57:19 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Although I think it might be more readable to have "and", "or"
 etc as operators. This is actually allowed in C++:
=20
 "a && b" <=3D> "a and b"=E2=80=A6
i prefer that to "&&" and "||", tbh, not because i have pascal/oberon=20 background, but 'cause it's harder to make a typo. "|" is binary, "or" is=20 logic. simple and easy. p.s. and i hate that "true" converts to "1". in many forth systems "true"=20 is "-1", and it's way better. `a&cast(int)true` actually works for the=20 most widely used case (when a.sizeof <=3D int.sizeof), for examplt.=
Jun 18 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 11:51:04 UTC, ketmar wrote:
 On Thu, 18 Jun 2015 09:57:19 +0000, Ola Fosheim Grøstad wrote:

 Although I think it might be more readable to have "and", "or" 
 etc as operators. This is actually allowed in C++:
 
 "a && b" <=> "a and b"…
i prefer that to "&&" and "||", tbh, not because i have pascal/oberon background, but 'cause it's harder to make a typo. "|" is binary, "or" is logic. simple and easy.
Yes, there is something clean looking about "and"/"or", in my toying with syntaxes I've found that sigils somehow more easily are perceived as noise than words. It is a very different balance to get right as you add more features.
 p.s. and i hate that "true" converts to "1". in many forth 
 systems "true" is "-1", and it's way better. `a&cast(int)true` 
 actually works for the most widely used case (when a.sizeof <= 
 int.sizeof), for examplt.
I'm all for very strict typing, but converting true to int is by mathematical convention done to 1. On some CPUs it is also the hardware value. *shrugs*
Jun 18 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 18 Jun 2015 12:19:03 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 p.s. and i hate that "true" converts to "1". in many forth systems
 "true" is "-1", and it's way better. `a&cast(int)true` actually works
 for the most widely used case (when a.sizeof <=3D int.sizeof), for
 examplt.
=20 I'm all for very strict typing, but converting true to int is by mathematical convention done to 1. On some CPUs it is also the hardware value. *shrugs*
never heard of such convention. ;-)=
Jun 18 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:mloslo$1o7v$1 digitalmars.com...

 I have yet to see a single case of "needing" boolean versions that could 
 not be refactored into something much more readable and maintainable that 
 did not use such.

 Over time, I've gotten rid of most of that stuff from the dmd source code, 
 and the result has been quite pleasing.
Walter, how about a compromise? If we allow setting versions to boolean expression then it becomes much easier to use it the way you suggest, while still requiring a (hopefully) sensible name and discouraging making a mess. eg version(A) { version(B) { } else { version=NeedsSomeCode; } } becomes version NeedsSomeCode = A && !B An example from real code would be version valistIsCharPointer = (Linux && LP32) || Windows; This pattern does appear frequently in your compiler code, are you for or against seeing it in D?
Jun 25 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 26 June 2015 at 06:06:09 UTC, Daniel Murphy wrote:
 Walter, how about a compromise?

 If we allow setting versions to boolean expression then it 
 becomes much easier to use it the way you suggest, while still 
 requiring a (hopefully) sensible name and discouraging making a 
 mess.

 eg

 version(A)
 {
   version(B)
   {
   }
   else
   {
      version=NeedsSomeCode;
   }
 }

 becomes

 version NeedsSomeCode = A && !B

 An example from real code would be

 version valistIsCharPointer = (Linux && LP32) || Windows;

 This pattern does appear frequently in your compiler code, are 
 you for or against seeing it in D?
So you're trying to avoid writing this? version(linux) version(D_LP32) version = valistIsCharPointer; else version(Windows) version = valistIsCharPointer; While your version is more concise, I actually think the current form is more clear.
Jun 27 2015
parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
 On Friday, 26 June 2015 at 06:06:09 UTC, Daniel Murphy wrote:
 Walter, how about a compromise?

 If we allow setting versions to boolean expression then it becomes much easier
to use it the way you suggest, while still requiring a (hopefully) sensible
name and discouraging making a mess.

 eg

 version(A)
 {
   version(B)
   {
   }
   else
   {
      version=NeedsSomeCode;
   }
 }

 becomes

 version NeedsSomeCode = A && !B

 An example from real code would be

 version valistIsCharPointer = (Linux && LP32) || Windows;

 This pattern does appear frequently in your compiler code, are you for or
against seeing it in D?
So you're trying to avoid writing this? version(linux) version(D_LP32) version = valistIsCharPointer; else version(Windows) version = valistIsCharPointer; While your version is more concise, I actually think the current form is more clear.
And wrong. Spot the bug. That's the real reason why 'version' needs to be banned from the codebase. You should *never* use D's 'version'. artur
Jun 28 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
 On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
 So you're trying to avoid writing this?
 
 version(linux) version(D_LP32)
     version = valistIsCharPointer;
 else version(Windows)
     version = valistIsCharPointer;
 
 While your version is more concise, I actually think the 
 current form is more clear.
And wrong. Spot the bug.
Eh, that idiom is not commonly used so I wasn't exactly clear on the syntax, but you're presumably referring to the need for braces? version(linux) { version(D_LP32) version = valistIsCharPointer; } else version(Windows) version = valistIsCharPointer; I actually find this even more clear, the best of the bunch. :)
 That's the real reason why 'version' needs to be banned from 
 the codebase. You should *never* use D's 'version'.
If you think it needs to be banned because of some non-obvious bracing syntax, you don't have much to stand on.
Jun 28 2015
parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/28/15 16:21, Joakim via Digitalmars-d wrote:
 On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
 On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
 So you're trying to avoid writing this?

 version(linux) version(D_LP32)
     version = valistIsCharPointer;
 else version(Windows)
     version = valistIsCharPointer;

 While your version is more concise, I actually think the current form is more
clear.
And wrong. Spot the bug.
Eh, that idiom is not commonly used so I wasn't exactly clear on the syntax, but you're presumably referring to the need for braces?
I didn't even look as far as the 'else', but that is another good reason to avoid 'version'. What I was referring to was the use of subtly different identifiers - the original used 'Linux', but your version has 'linux'. Such changes are hard to see even in a four-liner; they are almost impossible to catch in a larger change. Which will likely pass code review, where the focus in on logic, not spelling. The compiler is supposed to catch the latter kind of errors, but it has no chance to do this because of D's 'version' semantics. So performance- and even security-relevant issues can remain unnoticed, until someone has to figure out why something that can't happen does happen, or why a platform feature isn't being used. The situation is bad enough when dealing with predefined identifiers, but gets worse with local user- defined ones. You might get 'Linux' vs 'linux' right, but is it 'freebsd', 'freeBSD', 'FreeBSD' or 'Free_BSD'? Unless you happen to use that OS, you /will/ get it wrong. When reviewing code, will you always spot 'version(ALPHA)', 'version(Sparc)', 'version(x86_64)' and 'version(MIPS_64)'? You're even less likely to notice: version(vaListIsCharPointer) ...
 That's the real reason why 'version' needs to be banned from the codebase. You
should *never* use D's 'version'.
D has another feature that provides the same functionality and is not affected by the problem, so just use that -- 'static if'. And have just one exception; a 'config' module which is allowed to access predefined version identifiers (but does not define any local ones, just normal enum constants). Not perfect, but at least this issue will not bite you anywhere else. If someone writes static if (config.Linux) ... or static if (config.vaListIsCharPointer) ... then the compiler will always catch the bug. The other D-version problems mentioned in this thread will then disappear too. artur
Jul 04 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Saturday, 4 July 2015 at 15:04:32 UTC, Artur Skawina wrote:
 What I was referring to was the use of subtly different 
 identifiers
 - the original used 'Linux', but your version has 'linux'. Such
 changes are hard to see even in a four-liner; they are almost
 impossible to catch in a larger change. Which will likely pass 
 code
 review, where the focus in on logic, not spelling. The compiler 
 is
 supposed to catch the latter kind of errors, but it has no 
 chance to
 do this because of D's 'version' semantics. So performance- and 
 even
 security-relevant issues can remain unnoticed, until someone 
 has to
 figure out why something that can't happen does happen, or why a
 platform feature isn't being used.
Well, technically, _he_ was wrong, as D defines 'linux' and not 'Linux', and I was just correcting Daniel. Note also that I changed it to D_LP32, even though neither one is predefined, because that at least follows the naming convention of D_LP64, which does exist.
 The situation is bad enough when
 dealing with predefined identifiers, but gets worse with local 
 user-
 defined ones. You might get 'Linux' vs 'linux' right, but is it
 'freebsd', 'freeBSD', 'FreeBSD' or 'Free_BSD'? Unless you 
 happen to
 use that OS, you /will/ get it wrong.
 When reviewing code, will you always spot 'version(ALPHA)',
 'version(Sparc)', 'version(x86_64)' and 'version(MIPS_64)'?
 You're even less likely to notice:

    version(vaListIsCharPointer)
      ...
A fair criticism, but one that also applies to the C++ #ifdefs I quoted previously.
 That's the real reason why 'version' needs to be banned from 
 the codebase. You should *never* use D's 'version'.
D has another feature that provides the same functionality and is not affected by the problem, so just use that -- 'static if'. And have just one exception; a 'config' module which is allowed to access predefined version identifiers (but does not define any local ones, just normal enum constants). Not perfect, but at least this issue will not bite you anywhere else. If someone writes static if (config.Linux) ... or static if (config.vaListIsCharPointer) ... then the compiler will always catch the bug. The other D-version problems mentioned in this thread will then disappear too.
Only drawback is that you have to import that config module everywhere for those constants to be defined. I agree that mistyping and checking a large array of version constants can cause problems, don't think it's enough to throw "version" out though.
Jul 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/4/2015 2:24 PM, Joakim wrote:
 I agree that mistyping and checking a large array of
 version constants can cause problems
It's one reason why this style is recommended: version (linux) { ... } else version (Windows) { ... } else static assert(0);
Jul 04 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 4 July 2015 at 22:43:40 UTC, Walter Bright wrote:
 On 7/4/2015 2:24 PM, Joakim wrote:
 I agree that mistyping and checking a large array of
 version constants can cause problems
It's one reason why this style is recommended: version (linux) { ... } else version (Windows) { ... } else static assert(0);
Yeah, and while version identifiers can certainly be error-prone, it's not like allowing arbitrary conditions or even &&ing and ||ing version identifiers would make them _less_ error-prone. We're dealing with the type of thing that seems to just be fundamentally error-prone such that the best that we can do is disallow some of the worst cases and adopt practices which mitigate the risk. We _do_ need version statements (or an equivalent) though, otherwise it would be be pretty hard to write cross-platform code. - Jonathan M Davis
Jul 04 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2015 11:06 PM, Daniel Murphy wrote:
 This pattern does appear frequently in your compiler code, are you for or
 against seeing it in D?
Against. A lot of the compiler code is very, very old, and is not representative of modern thinking. I've also been pretty successful at removing that stuff from the front end, and as you know, have been working on the backend as well.
Jun 27 2015
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sun, 28 Jun 2015 00:10:28 -0400, Walter Bright
<newshound2 digitalmars.com> wrote:

 On 6/25/2015 11:06 PM, Daniel Murphy wrote:
 This pattern does appear frequently in your compiler code, are you for  
 or
 against seeing it in D?
Against. A lot of the compiler code is very, very old, and is not representative of modern thinking. I've also been pretty successful at removing that stuff from the front end, and as you know, have been working on the backend as well.
FWIW, I've thought through most of my use cases, and it seems I can do without this feature(both mine and Daniels suggestions). This is mainly because I've decided to write anything close to the system in C++. If/When the day comes that system APIs are written in D, this may change, but I don't see this happening in the foreseeable future. IMO, the D community's time would be better spent improving D/C++ interop than trying to make D a systems language. At a glance, I don't see a binding for OpenCV or FBX SDK, and although there are many bindings for OpenGL and such, I wouldn't feel safe relying on them to be up to date or complete. The lesser evil clearly seems to be writing some C++. Bit
Jun 29 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2015 8:30 AM, bitwise wrote:
 FWIW, I've thought through most of my use cases, and it seems I can do without
 this feature(both mine and Daniels suggestions). This is mainly because I've
 decided to write anything close to the system in C++. If/When the day comes
that
 system APIs are written in D, this may change, but I don't see this happening
in
 the foreseeable future. IMO, the D community's time would be better spent
 improving D/C++ interop than trying to make D a systems language. At a glance,
I
 don't see a binding for OpenCV or FBX SDK, and although there are many bindings
 for OpenGL and such, I wouldn't feel safe relying on them to be up to date or
 complete. The lesser evil clearly seems to be writing some C++.
I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.
Jun 29 2015
next sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Mon, 29 Jun 2015 22:30:50 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 6/29/2015 8:30 AM, bitwise wrote:
 FWIW, I've thought through most of my use cases, and it seems I can do  
 without
 this feature(both mine and Daniels suggestions). This is mainly because  
 I've
 decided to write anything close to the system in C++. If/When the day  
 comes that
 system APIs are written in D, this may change, but I don't see this  
 happening in
 the foreseeable future. IMO, the D community's time would be better  
 spent
 improving D/C++ interop than trying to make D a systems language. At a  
 glance, I
 don't see a binding for OpenCV or FBX SDK, and although there are many  
 bindings
 for OpenGL and such, I wouldn't feel safe relying on them to be up to  
 date or
 complete. The lesser evil clearly seems to be writing some C++.
I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.
Was pretty sure I worded that wrong. I'm willing to concede at this point that if I was writing some fresh new systems code, I could deal with the limitations of 'version', and that it does seem like good practice not to spam preprocessors/version everywhere, but for me, a big selling point of D is _not_ having to re-write/refactor/re-think my code. From the point I picked up D, and having a strong background in C++, it just felt natural, and I was able to start programming with it immediately. I've been able to transfer over a lot of design-patterns/code with little to no effort. Still though, I think that with the dominance of C++ for system APIs, it makes more sense right now to keep the interop layer as narrow as possible, and just access the system from C++. I can then create a small group of interfaces for accessing graphics/audio/etc.. So I guess this nullifies my original grievance. Sorry for nagging :) Bit
Jun 29 2015
prev sibling next sibling parent "rsw0x" <anonymous anonymous.com> writes:
On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote:
 On 6/29/2015 8:30 AM, bitwise wrote:
 [...]
I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.
so is that a 'no, D will never get a real macro preprocessor'?
Jun 29 2015
prev sibling parent reply "bitwise" <bitwise.pvt gmail.com> writes:
On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote:
 I don't believe a macro processor is necessary to write systems 
 code, nor do I believe version expressions are, either.
Waiiit a minute...reading this again, it seems you are talking about writing code for a single system. In that case, yea, I suppose you can get by without versions. The market in multi-platform mobile apps is not something that should be ignored though.
Jun 30 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 30 June 2015 at 15:55:49 UTC, bitwise wrote:
 On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote:
 I don't believe a macro processor is necessary to write 
 systems code, nor do I believe version expressions are, either.
Waiiit a minute...reading this again, it seems you are talking about writing code for a single system. In that case, yea, I suppose you can get by without versions. The market in multi-platform mobile apps is not something that should be ignored though.
You need version blocks to distinguish between platforms (be it OSes or architectures or whatever), but code like that should be wrapped at a fairly low level, and most code shouldn't have anything like that in it. e.g. druntime has tons of version blocks, whereas Phobos has relatively few. Certainly, in general, if you're using complex expressions for versions, you should probably be rethinking how you're doing your code. I've dealt with code before that shared code across multiple products and altered its behavior via ifdefs, and it was a _disaster_. It would have been _far_ cleaner to just separate it out via libraries and section off the system-specific code such that it was contained and generally small. Once in a while, being able to && or || version identifiers like linux and FreeBSD would be nice, but on the whole, I have to agree that if you're doing much of that, it's just a recipe for disaster. I suppose that the problem is that it's just useful enough in some cases that it's annoying not to have it, but if we _did_ have it, it would be abused like there's no tomorrow. - Jonathan M Davis
Jun 30 2015
parent "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 30 June 2015 at 16:19:56 UTC, Jonathan M Davis wrote:
 On Tuesday, 30 June 2015 at 15:55:49 UTC, bitwise wrote:
 On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote:
 I don't believe a macro processor is necessary to write 
 systems code, nor do I believe version expressions are, 
 either.
Waiiit a minute...reading this again, it seems you are talking about writing code for a single system. In that case, yea, I suppose you can get by without versions. The market in multi-platform mobile apps is not something that should be ignored though.
You need version blocks to distinguish between platforms (be it OSes or architectures or whatever), but code like that should be wrapped at a fairly low level, and most code shouldn't have anything like that in it. e.g. druntime has tons of version blocks, whereas Phobos has relatively few. Certainly, in general, if you're using complex expressions for versions, you should probably be rethinking how you're doing your code. I've dealt with code before that shared code across multiple products and altered its behavior via ifdefs, and it was a _disaster_. It would have been _far_ cleaner to just separate it out via libraries and section off the system-specific code such that it was contained and generally small. Once in a while, being able to && or || version identifiers like linux and FreeBSD would be nice, but on the whole, I have to agree that if you're doing much of that, it's just a recipe for disaster. I suppose that the problem is that it's just useful enough in some cases that it's annoying not to have it, but if we _did_ have it, it would be abused like there's no tomorrow.
For a concrete example from my experience, take a massively multi-platform codebase like Chromium, which is littered with #ifdef logic like this, ie #if defined(OS_CHROMEOS) || defined(OS_WIN) || defined(OS_LINUX): http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/about_flags.cc?r1=279969&r2=279970& It would be better if that logic weren't spread out everywhere and was abstracted out into a single place, replaced by a more specific named feature, as they've attempted to do a little here: http://src.chromium.org/viewvc/chrome/trunk/src/build/build_config.h Specifically, they can simply use USE_TCMALLOC instead of #if (defined(OS_WIN) || defined(OS_LINUX) || defined(OS_ANDROID)) && !defined(NO_TCMALLOC) everywhere in the source. Yes, that means you sometimes need to check build_config.h to see how USE_TCMALLOC is defined when reading those other files, rather than always having the logic on hand. That's the trade-off, I think it's worth it. I believe Walter is simply trying to enforce such centralization of version logic, and I agree with him.
Jun 30 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/30/2015 8:55 AM, bitwise wrote:
 Waiiit a minute...reading this again, it seems you are talking about writing
 code for a single system.

 In that case, yea, I suppose you can get by without versions. The market in
 multi-platform mobile apps is not something that should be ignored though.
D has multi-platform support in the D runtime library and it works. So do other languages, that don't even have version declarations.
Jul 02 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 29 Jun 2015 11:30:52 -0400, bitwise wrote:

 IMO,
 the D community's time would be better spent improving D/C++ interop
 than trying to make D a systems language.
but that interop is excellent now! for, see, if some library has no C API,=20 only C++ API, authors of that library are heavily brain-damaged, and the=20 troubles library brings will be much greater than any benefits one can=20 get. and if it has C API, most of it can be translated with sed and=20 manually fixed (i'm doing that any time i need a new binding).=
Jun 30 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 1 July 2015 at 06:53:53 UTC, ketmar wrote:
 but that interop is excellent now! for, see, if some library 
 has no C API, only C++ API, authors of that library are heavily 
 brain-damaged, and the troubles library brings will be much 
 greater than any benefits one can get.
Quite a few niche-libraries are C++ only. It does not help C that Microsoft is ignoring implementation of new C standards in favour of new C++ standards.
Jul 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Quite a few niche-libraries are C++ only.
throw 'em away, they full of bugs and broken code anyway.=
Jul 01 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:
 On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Grøstad wrote:

 Quite a few niche-libraries are C++ only.
throw 'em away, they full of bugs and broken code anyway.
Qt? AFAIK, it's C++-only, and it's widely considered to be one of the best GUI toolkits out there. Sure, having a library be in C or provide C bindings makes it more compatible with other languages, which is nice you're using another language, but the fact that someone chooses to use C++ instead of C for their library doesn't make it junk, and plenty of folks care primarily about C++, in which case, it's a non-issue. - Jonathan M Davis
Jul 01 2015
next sibling parent "rsw0x" <anonymous anonymous.com> writes:
On Wednesday, 1 July 2015 at 13:43:27 UTC, Jonathan M Davis wrote:
 On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:
 On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Grøstad wrote:

 Quite a few niche-libraries are C++ only.
throw 'em away, they full of bugs and broken code anyway.
Qt? AFAIK, it's C++-only, and it's widely considered to be one of the best GUI toolkits out there. Sure, having a library be in C or provide C bindings makes it more compatible with other languages, which is nice you're using another language, but the fact that someone chooses to use C++ instead of C for their library doesn't make it junk, and plenty of folks care primarily about C++, in which case, it's a non-issue. - Jonathan M Davis
qt is good because it's far, _far_ more than a UI toolkit. It's the exact opposite of something that D needs. qt has support for XML, json, databases, audio backend, memory management system, scripting engine, web browser, etc etc it reimplements 99% of the C++ standard library for D, qt is overengineered junk.
Jul 01 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 01 Jul 2015 13:43:26 +0000, Jonathan M Davis wrote:

 On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:
 On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=
:
 Quite a few niche-libraries are C++ only.
throw 'em away, they full of bugs and broken code anyway.
=20 Qt? AFAIK, it's C++-only, and it's widely considered to be one of the best GUI toolkits out there.
for C++. all so-called "bindings" are ugly as hell. mostly 'cause Qt is=20 not a "GUI toolkit", but a programming platform, tied to C++. using it as=20 library outside of C++ world is a huge mistake.
 but the fact that someone chooses to use
 C++ instead of C for their library doesn't make it junk
it does. there is no single reason to write a *library* in C++, if it's=20 intended to be used outside of C++ world.
 and plenty of folks care primarily about C++, in which case,
 it's a non-issue.
so let 'em be in their wonderful C++ world. no need to drag that=20 abomination to other worlds.=
Jul 01 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
 using it as library outside of C++ world is a huge mistake.
I can't agree with this. PyQt is the most usable UI toolkit for Python in my experience. - David
Jul 01 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 06:12:26 +0000, David Nadlinger wrote:

 On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
 using it as library outside of C++ world is a huge mistake.
=20 I can't agree with this. PyQt is the most usable UI toolkit for Python in my experience.
except that python is a one big huge mistake... ;-)=
Jul 02 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
 so let 'em be in their wonderful C++ world. no need to drag 
 that abomination to other worlds.
You can't really write libraries in C if you need inlining to get good performance. Such libraries are usually written in C++. To get those ported and maintained you need a significant user-mass. Maybe Rust can do it if they can sustain growth, but it will take several years to get there. So good C++ interop is the cheap option.
Jul 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 08:15:38 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Wednesday, 1 July 2015 at 14:30:26 UTC, ketmar wrote:
 so let 'em be in their wonderful C++ world. no need to drag that
 abomination to other worlds.
=20 You can't really write libraries in C if you need inlining to get good performance. Such libraries are usually written in C++.
ahem. i don't even know how i managed to do that all the time with=20 "static inline" in .h files... i'm a black magicman!=
Jul 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 July 2015 at 10:29:39 UTC, ketmar wrote:
 ahem. i don't even know how i managed to do that all the time 
 with "static inline" in .h files... i'm a black magicman!
Doesn't matter what you are, but what language core libraries are written in.
Jul 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 11:39:11 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Thursday, 2 July 2015 at 10:29:39 UTC, ketmar wrote:
 ahem. i don't even know how i managed to do that all the time with
 "static inline" in .h files... i'm a black magicman!
=20 Doesn't matter what you are, but what language core libraries are written in.
"You can't really write libraries in C if you need inlining to get good performance." ahem. i can. with C. what am i doing wrong?=
Jul 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 July 2015 at 11:55:48 UTC, ketmar wrote:
 ahem. i can. with C. what am i doing wrong?
Well, you can't because you don't have templates. The most recent C version have a hacked up version of generics, but who knows if/when Microsoft will implement it. People write core libraries in C++. Why they do it is not the main point, but they actually have good reasons to choose C++ over C no matter what C-wizzkids with C++-allergies claim… ;^]
Jul 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 12:35:18 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Thursday, 2 July 2015 at 11:55:48 UTC, ketmar wrote:
 ahem. i can. with C. what am i doing wrong?
=20 Well, you can't because you don't have templates.
that's why my hashtables supports alot of types, including ints, strings,=20 structs and inlined? hm...
 People write core libraries in C++. Why they do it is not the main
 point, but they actually have good reasons to choose C++ over C no
 matter what C-wizzkids with C++-allergies claim=E2=80=A6 ;^]
yes. the main reason is "let's prevent using our library in any sane=20 language!"=
Jul 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 July 2015 at 14:42:10 UTC, ketmar wrote:
 that's why my hashtables supports alot of types, including 
 ints, strings, structs and inlined? hm...
Hashing isn't type-dependent. You can't really do it well in C with things like extensible physics and sound synthesis.
 People write core libraries in C++. Why they do it is not the 
 main point, but they actually have good reasons to choose C++ 
 over C no matter what C-wizzkids with C++-allergies claim… 
 ;^]
yes. the main reason is "let's prevent using our library in any sane language!"
Nah, it's more like "let's solve this in a language where this can be done in a convenient manner and will be used by many people". As for D... I'm not really sure if D can get good C++ interop without changing language semantics. A 75% solution isn't really good enough to cover libraries that rely heavily on template composition.
Jul 02 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 03 Jul 2015 06:11:49 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Nah, it's more like "let's solve this in a language where this can be
 done in a convenient manner and will be used by many people".
wait, are you talking about C here? 'cause it's about C.=
Jul 03 2015
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Wed, 01 Jul 2015 02:53:53 -0400, ketmar <ketmar ketmar.no-ip.org> wrote:

 On Mon, 29 Jun 2015 11:30:52 -0400, bitwise wrote:

 IMO,
 the D community's time would be better spent improving D/C++ interop
 than trying to make D a systems language.
but that interop is excellent now! for, see, if some library has no C API, only C++ API, authors of that library are heavily brain-damaged, and the troubles library brings will be much greater than any benefits one can get. and if it has C API, most of it can be translated with sed and manually fixed (i'm doing that any time i need a new binding).
It is pretty good, but it's the little things, like these: 1) no clear specification/wiki with info on which compilers are supposed to work together -dmd and xcode default compiler work, but I found this out through trial and error 2) need to qualify your extern(C++) interface overrides with "extern(C++)" -this shouldn't be necessary 3) extern(C++) interfaces/classes can't have virtual destructors -even if you can't call it, as the docs specify, you should be able to put "~this();" or something into an extern(C++) interface as a placeholder so that your C++ class can have a virtual destructor. 4) C++ namespaces shouldn't conflict with module namespace scope -this should work: module N; extern(C++, N) { interface X{} void foo(); } If the above cannot work, we should be able to do something like this: module N; extern(C++, alias M N) or extern(C++, M = N) { void foo(); } M.foo(); N.foo(); // error, foo is in "M" scope in D-land Bit
Jul 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 02:08:58 -0400, bitwise wrote:

 It is pretty good, but it's the little things, like these:
the whole thing i'm talking about is "no C++ interop is necessary,=20 eVaR!" ;-)=
Jul 02 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 2 July 2015 at 10:28:16 UTC, ketmar wrote:
 On Thu, 02 Jul 2015 02:08:58 -0400, bitwise wrote:

 It is pretty good, but it's the little things, like these:
the whole thing i'm talking about is "no C++ interop is necessary, eVaR!" ;-)
Well, you're entitled to your opinion, and you're definitely free to avoid C++ libraries if that what you want, but there are plenty of D users who want good C++ interop (and for some projects, pretty much require it - especially the corporate folks), so there's actually a fairly high demand for it. And part of why the C++ interop that we have is as good as it is now is because it was needed to port the compiler's frontend to D and have it still work with the backends of the three main compilers. So, it's there because it serves a very practical purpose. So, use it or don't, but don't expect everyone to agree with you that interoperability with C++ is useless. - Jonathan M Davis
Jul 02 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Jul 2015 11:09:23 +0000, Jonathan M Davis wrote:

 Well, you're entitled to your opinion, and you're definitely free to
 avoid C++ libraries if that what you want, but there are plenty of D
 users who want good C++ interop (and for some projects, pretty much
 require it - especially the corporate folks), so there's actually a
 fairly high demand for it. And part of why the C++ interop that we have
 is as good as it is now is because it was needed to port the compiler's
 frontend to D and have it still work with the backends of the three main
 compilers.
 So, it's there because it serves a very practical purpose.
and still not working reliably, partly due to absence of standardized=20 mangling schemes and ABI in C++. this is a neverending chase.
 So, use it or don't, but don't expect everyone to agree with you that
 interoperability with C++ is useless.
but i can try! ;-)=
Jul 02 2015
prev sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Sun, 14 Jun 2015 06:35:30 -0400, Joakim <dlang joakim.fea.st> wrote:

 Walter is coming from long experience with this,and even with my limited  
 experience with such logic, I'm grateful for it, as dealing with more  
 complex versions of such logic is a royal PITA.
He's an expert, no doubt, but I've learned not to put people on a pedestal because of their level of experience. Anyone can be wrong, or change their mind. Bit
Jun 14 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/13/15 4:57 PM, bitwise wrote:
 What is the rationale for not allowing multiple version conditions?

 Example:

 version(iOS || Android) {
      pthread_create(...)
 }
 else version(Win32) {
      CreateThread(...)
 }

 I wasn't able to find the conversations on this.

 I heard rumors in DLearn that Walter was against this, but I'm wondering
 if the sentiment has changed at this point. Is there is any wiggle room
 for at least adding "||" so that code can be shared between platforms?
No, it hasn't changed. Walter will not accept this, I don't think there's any hope for it. Just use the static if trick. -Steve
Jun 13 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/13/2015 6:51 PM, Steven Schveighoffer wrote:
 Just use the static if trick.
Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary. You can use it in your own code if you like, but I strongly recommend against that and suggest instead the one of the myriad ways I've suggested before for straightforwardly adapting to versions.
Jun 16 2015
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote:
 On 6/13/2015 6:51 PM, Steven Schveighoffer wrote:
 Just use the static if trick.
Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary.
Are you referring to this? https://github.com/D-Programming-Language/druntime/commit/54ca71b154fd9476520a63e30a50980af8927a56 If yes, I would claim that this is hardly relevant to this discussion, but I couldn't find any other druntime commits where you changed static ifs. - David
Jun 16 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2015 6:28 AM, David Nadlinger wrote:
 On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote:
 On 6/13/2015 6:51 PM, Steven Schveighoffer wrote:
 Just use the static if trick.
Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary.
Are you referring to this? https://github.com/D-Programming-Language/druntime/commit/54ca71b154fd9476520a63e30a50980af8927a56 If yes, I would claim that this is hardly relevant to this discussion, but I couldn't find any other druntime commits where you changed static ifs. - David
No, there was another one, but I don't remember the details.
Jun 16 2015
prev sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Tuesday, 16 June 2015 at 09:55:34 UTC, Walter Bright wrote:
 On 6/13/2015 6:51 PM, Steven Schveighoffer wrote:
 Just use the static if trick.
Someone had used the static if trick in druntime. It caused some weird dependency bugs. I removed it - it turned out to be confusing, buggy, and wholly unnecessary.
Probably because of this forward referencing bug with "static if," which I've run into myself: https://issues.dlang.org/show_bug.cgi?id=3743 I agree with you about using version and I applaud your attempt to centralize such version logic, just pointing out that bugs in the implementation of "static if" are not a good way to enforce this. ;)
Jun 16 2015
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
bitwise wrote:

 for at least adding "||" so that code can be shared between platforms?
Sureley it is a pita to write: version( iOS) version= iOS; else version( Android) version= Android; else version= neither; version( neither) version= neither; else version=iOSorAndroid; version( iOSorAndroid){ // ... } -manfred
Jun 14 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
 bitwise wrote:

 for at least adding "||" so that code can be shared between 
 platforms?
Sureley it is a pita to write: version( iOS) version= iOS; else version( Android) version= Android; else version= neither; version( neither) version= neither; else version=iOSorAndroid; version( iOSorAndroid){ // ... }
It is, but it is only a 0.0001% source code increase that can be hidden in a config file. I really hope that the next two release will focus on bugfixes, transitioning to D and refactoring. If DMD source code was lean D code, it would attract more developers to the compiler. So avoiding changes now would pay off in terms of long term evolution. You cannot both transition to D and focus on changes. Freeze the feature set...
Jun 14 2015
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sun, 14 Jun 2015 09:36:17 -0400, Ola Fosheim Gr=F8stad  =

<ola.fosheim.grostad+dlang gmail.com> wrote:

 On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
 bitwise wrote:

 for at least adding "||" so that code can be shared between platform=
s?
 Sureley it is a pita to write:

 version( iOS) version=3D iOS;
 else version( Android) version=3D Android;
 else version=3D neither;
 version( neither) version=3D neither;
 else version=3DiOSorAndroid;

 version( iOSorAndroid){
    // ...
 }
It is, but it is only a 0.0001% source code increase that can be hidde=
n =
 in a config file.
It's not just about the code increase though. What if I need AndroidOrWP= 8, = and I also need Win32OrWin64? This can quickly become a much larger pita= .
 I really hope that the next two release will focus on bugfixes,  =
 transitioning to D and refactoring.

 If DMD source code was lean D code, it would attract more developers t=
o =
 the compiler. So avoiding changes now would pay off in terms of long  =
 term evolution.

 You cannot both transition to D and focus on changes. Freeze the featu=
re =
 set...
True. Maybe I'm underestimating the amount of effort that is going into = = this. I admit I don't know much about whats going on with the DDMD stuff= . Bit
Jun 14 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 14 June 2015 at 16:53:19 UTC, bitwise wrote:
 It's not just about the code increase though. What if I need 
 AndroidOrWP8, and I also need Win32OrWin64? This can quickly 
 become a much larger pita.
Yes, I think this is related to person-specific experiences. Some people insist on keeping all OS-specific code in separate files, others don't… A person with this mindset would version(Windows) to get to a Windows file and then version on Win32 etc in that file… Not saying it is better, but I think that is why people think differently about this issue.
 True. Maybe I'm underestimating the amount of effort that is 
 going into this. I admit I don't know much about whats going on 
 with the DDMD stuff.
Me neither. I just know that I have lost interest in the C++ version of DMD now that there is a move towards D. And I look forward to see an idiomatic D version. I guess only people who know the codebase very well can do that refactoring so let's not tempt them into fixing minor language issues, that's my thinking. Refactoring is kinda tedious… so I'm sure it would be easy to distract anyone into adding more features instead. ;-)
Jun 14 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2015 9:53 AM, bitwise wrote:
 What if I need AndroidOrWP8, and I
 also need Win32OrWin64? This can quickly become a much larger pita.
If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version.
Jun 16 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:mlorvv$1nb6$1 digitalmars.com...

 On 6/14/2015 9:53 AM, bitwise wrote:
 What if I need AndroidOrWP8, and I
 also need Win32OrWin64? This can quickly become a much larger pita.
If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version.
This works well until the code that needs to be versioned is split over many source files, and now each one needs to duplicate the version setting code.
Jun 16 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2015 6:06 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:mlorvv$1nb6$1 digitalmars.com...

 On 6/14/2015 9:53 AM, bitwise wrote:
 What if I need AndroidOrWP8, and I
 also need Win32OrWin64? This can quickly become a much larger pita.
If you need those, the design is wrong. It is better to think about what the code is trying to do with Android or WP8, and label *that* a version.
This works well until the code that needs to be versioned is split over many source files, and now each one needs to duplicate the version setting code.
If this is resulting, you're doing it wrong. Abstract the concept into a template or function, and put that in a separate module. (Much like how Port:: works.)
Jun 16 2015
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 6/14/2015 10:36 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
 bitwise wrote:

 for at least adding "||" so that code can be shared between platforms?
Sureley it is a pita to write: version( iOS) version= iOS; else version( Android) version= Android; else version= neither; version( neither) version= neither; else version=iOSorAndroid; version( iOSorAndroid){ // ... }
It is, but it is only a 0.0001% source code increase that can be hidden in a config file.
Not using version statements. They only apply to the module in which they are declared. To use it in multiple modules, you need static if and enums. I like that better than the version statements anyway, so if we aren't going to ever get boolean versions, I'll settle for the static if approach.
Jun 15 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 15 Jun 2015 17:25:07 +0900, Mike Parker wrote:

 On 6/14/2015 10:36 PM, "Ola Fosheim =3D?UTF-8?B?R3LDuHN0YWQi?=3D
 <ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Sunday, 14 June 2015 at 13:02:03 UTC, Manfred Nowak wrote:
 bitwise wrote:

 for at least adding "||" so that code can be shared between
 platforms?
Sureley it is a pita to write: version( iOS) version=3D iOS; else version( Android) version=3D Android; else version=3D neither; version( neither) version=3D neither; else version=3DiOSorAndroid; version( iOSorAndroid){ // ... }
It is, but it is only a 0.0001% source code increase that can be hidden in a config file.
Not using version statements. They only apply to the module in which they are declared. To use it in multiple modules, you need static if and enums. I like that better than the version statements anyway, so if we aren't going to ever get boolean versions, I'll settle for the static if approach.
if only there is a way to define such enums from command line, akin to "- version"...=
Jun 15 2015
parent "anonymous" <MonkeyCodr skdjfksjf.gr> writes:
On Monday, 15 June 2015 at 10:56:43 UTC, ketmar wrote:
 if only there is a way to define such enums from command line, 
 akin to "- version"...
+1. predefined versions can be easily set at CT as enum an used with static if() but with this feature is would make more sense.
Jul 01 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 15 June 2015 at 08:25:08 UTC, Mike Parker wrote:
 Not using version statements. They only apply to the module in 
 which they are declared. To use it in multiple modules, you 
 need static if and enums.
Ack… That was new to me. What is the reasoning behind this?
 I like that better than the version statements anyway, so if we 
 aren't going to ever get boolean versions, I'll settle for the 
 static if approach.
Might as well.
Jun 15 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 15 Jun 2015 12:48:31 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Monday, 15 June 2015 at 08:25:08 UTC, Mike Parker wrote:
 Not using version statements. They only apply to the module in which
 they are declared. To use it in multiple modules, you need static if
 and enums.
=20 Ack=E2=80=A6 That was new to me. What is the reasoning behind this?
module processing order is not defined. so module A can try to define=20 some version, and module B then try to check it, but compiler chooses to=20 process module B first, and... KABOOM! compiler is free to process=20 modules in parallel too, which makes things even more complicated. besides, let's imagine this code: version(abc) { ... } // abc must not be defined import mymodule_that_defines_abc; version(abc) { ... } // abc must be defined but! the specs says that module import order (and even position) doesn't=20 matter. so if you allow versions to go over module boundaries, this=20 innocent-looking code must have `abc` defined for both blocks. definetely=20 not what the author of the code wants. this also adds some more dependency issues too. all in all, it creates more problems than it is trying to solve.=
Jun 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 15 June 2015 at 15:10:10 UTC, ketmar wrote:
 all in all, it creates more problems than it is trying to solve.
Sounds like a bad excuse to me… All you need to require is that referenced global constants are actually… constant…
Jun 15 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 15 Jun 2015 21:47:26 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Monday, 15 June 2015 at 15:10:10 UTC, ketmar wrote:
 all in all, it creates more problems than it is trying to solve.
=20 Sounds like a bad excuse to me=E2=80=A6 All you need to require is that referenced global constants are actually=E2=80=A6 constant=E2=80=A6
nononono. i smell #define hell from C and all the problems it brings,=20 like careful ordering of #include.=
Jun 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 15 June 2015 at 21:59:43 UTC, ketmar wrote:
 nononono. i smell #define hell from C and all the problems it 
 brings, like careful ordering of #include.
Nah. #define does not define constants, but variable macros. Constants are constant _everywhere_. If ordering can effect that it isn't a _constant_.
Jun 15 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 15 Jun 2015 22:06:24 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Monday, 15 June 2015 at 21:59:43 UTC, ketmar wrote:
 nononono. i smell #define hell from C and all the problems it brings,
 like careful ordering of #include.
=20 Nah. #define does not define constants, but variable macros. =20 Constants are constant _everywhere_. If ordering can effect that it isn't a _constant_.
and `version` isn't a constant. it's a version id. it even lives in it's=20 own name space.=
Jun 17 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
 and `version` isn't a constant. it's a version id. it even 
 lives in it's own name space.
For no gain whatsoever.
Jun 17 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
 and `version` isn't a constant. it's a version id. it even lives in
 it's own name space.
=20 For no gain whatsoever.
and it can be removed for good if `static if` will be allowed at module=20 level. one of Walter's nightmares, i suppose.=
Jun 18 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 18 June 2015 at 11:53:31 UTC, ketmar wrote:
 On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:

 On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
 and `version` isn't a constant. it's a version id. it even 
 lives in it's own name space.
For no gain whatsoever.
and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.
I like the idea that "version" is about implementation and "if" is about semantics, but the D version of the concept is a bit raw at the moment.
Jun 18 2015
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/18/2015 01:53 PM, ketmar wrote:
 On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:

 On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
 and `version` isn't a constant. it's a version id. it even lives in
 it's own name space.
For no gain whatsoever.
and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.
static if is allowed at module level.
Jun 18 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 18 Jun 2015 17:12:31 +0200, Timon Gehr wrote:

 On 06/18/2015 01:53 PM, ketmar wrote:
 On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Gr=C3=83=C2=B8stad wrote=
:
 On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
 and `version` isn't a constant. it's a version id. it even lives in
 it's own name space.
For no gain whatsoever.
and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.
static if is allowed at module level.
oops. i was so sure that i can't do that, so i don't even bother to=20 check. my apologies.=
Jun 18 2015