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?




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

#endif


In Rust, there is attributes for this:


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?




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

 #endif


 In Rust, there is attributes for this:


 "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

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