Re: version: multiple conditions

2015-07-05 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-07-04 Thread Artur Skawina via Digitalmars-d
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


Re: version: multiple conditions

2015-07-04 Thread Joakim via Digitalmars-d

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.


Re: version: multiple conditions

2015-07-04 Thread Walter Bright via Digitalmars-d

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);



Re: version: multiple conditions

2015-07-03 Thread via Digitalmars-d

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.





Re: version: multiple conditions

2015-07-03 Thread ketmar via Digitalmars-d
On Fri, 03 Jul 2015 06:11:49 +, Ola Fosheim Grøstad 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.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread bitwise via Digitalmars-d

On Wed, 01 Jul 2015 02:53:53 -0400, ketmar ket...@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


Re: version: multiple conditions

2015-07-02 Thread via Digitalmars-d

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.




Re: version: multiple conditions

2015-07-02 Thread David Nadlinger via Digitalmars-d

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


Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
On Thu, 02 Jul 2015 06:12:26 +, 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.
 
 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... ;-)

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread Walter Bright via Digitalmars-d

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.




Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
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! ;-)

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
On Thu, 02 Jul 2015 08:15:38 +, Ola Fosheim Grøstad 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.
 
 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 
static inline in .h files... i'm a black magicman!

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-07-02 Thread via Digitalmars-d

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.





Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
On Thu, 02 Jul 2015 11:39:11 +, Ola Fosheim Grøstad 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!
 
 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?

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
On Thu, 02 Jul 2015 11:09:23 +, 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 
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! ;-)

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-02 Thread via Digitalmars-d

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… ;^]


Re: version: multiple conditions

2015-07-02 Thread ketmar via Digitalmars-d
On Thu, 02 Jul 2015 12:35:18 +, Ola Fosheim Grøstad wrote:

 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.

that's why my hashtables supports alot of types, including ints, strings, 
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… ;^]

yes. the main reason is let's prevent using our library in any sane 
language!

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-01 Thread anonymous via Digitalmars-d

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.


Re: version: multiple conditions

2015-07-01 Thread rsw0x via Digitalmars-d

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 +, 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.


Re: version: multiple conditions

2015-07-01 Thread Jonathan M Davis via Digitalmars-d

On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:

On Wed, 01 Jul 2015 10:16:13 +, 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


Re: version: multiple conditions

2015-07-01 Thread via Digitalmars-d

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.




Re: version: multiple conditions

2015-07-01 Thread ketmar via Digitalmars-d
On Wed, 01 Jul 2015 10:16:13 +, Ola Fosheim Grøstad wrote:

 Quite a few niche-libraries are C++ only.

throw 'em away, they full of bugs and broken code anyway.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-01 Thread ketmar via Digitalmars-d
On Wed, 01 Jul 2015 13:43:26 +, Jonathan M Davis wrote:

 On Wednesday, 1 July 2015 at 11:18:17 UTC, ketmar wrote:
 On Wed, 01 Jul 2015 10:16:13 +, 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.

for C++. all so-called bindings are ugly as hell. mostly 'cause Qt is 
not a GUI toolkit, but a programming platform, tied to C++. using it as 
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 
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 
abomination to other worlds.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-07-01 Thread ketmar via Digitalmars-d
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).

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-30 Thread Joakim via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-30 Thread Walter Bright via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-30 Thread bitwise via Digitalmars-d
On Mon, 29 Jun 2015 22:30:50 -0400, Walter Bright  
newshou...@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


Re: version: multiple conditions

2015-06-30 Thread rsw0x via Digitalmars-d

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'?


Re: version: multiple conditions

2015-06-30 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-06-30 Thread bitwise via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-30 Thread bitwise via Digitalmars-d

On Sun, 28 Jun 2015 00:10:28 -0400, Walter Bright
newshou...@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


Re: version: multiple conditions

2015-06-30 Thread Joakim via Digitalmars-d

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=279969r2=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.


Re: version: multiple conditions

2015-06-27 Thread Joakim via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-27 Thread Walter Bright via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-26 Thread Daniel Murphy via Digitalmars-d

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? 



Re: version: multiple conditions

2015-06-18 Thread via Digitalmars-d

On Thursday, 18 June 2015 at 11:53:31 UTC, ketmar wrote:

On Thu, 18 Jun 2015 01:44:08 +, 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.




Re: version: multiple conditions

2015-06-18 Thread ketmar via Digitalmars-d
On Thu, 18 Jun 2015 01:44:08 +, 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.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-18 Thread ketmar via Digitalmars-d
On Thu, 18 Jun 2015 09:57:19 +, 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.

p.s. and i hate that true converts to 1. in many forth systems true 
is -1, and it's way better. `acast(int)true` actually works for the 
most widely used case (when a.sizeof = int.sizeof), for examplt.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-18 Thread via Digitalmars-d

On Thursday, 18 June 2015 at 11:51:04 UTC, ketmar wrote:

On Thu, 18 Jun 2015 09:57:19 +, 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. `acast(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*




Re: version: multiple conditions

2015-06-18 Thread ketmar via Digitalmars-d
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 +, 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.

oops. i was so sure that i can't do that, so i don't even bother to 
check. my apologies.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-18 Thread ketmar via Digitalmars-d
On Thu, 18 Jun 2015 12:19:03 +, Ola Fosheim Grøstad wrote:

 p.s. and i hate that true converts to 1. in many forth systems
 true is -1, and it's way better. `acast(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*

never heard of such convention. ;-)

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-18 Thread Timon Gehr via Digitalmars-d

On 06/18/2015 01:53 PM, ketmar wrote:

On Thu, 18 Jun 2015 01:44:08 +, 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.


Re: version: multiple conditions

2015-06-18 Thread Jacob Carlborg via Digitalmars-d
On 17/06/15 10:03, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
ola.fosheim.grostad+dl...@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


Re: version: multiple conditions

2015-06-18 Thread via Digitalmars-d

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…




Re: version: multiple conditions

2015-06-17 Thread via Digitalmars-d

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.




Re: version: multiple conditions

2015-06-17 Thread ketmar via Digitalmars-d
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).

i also wonder why we have `opCmp` and `opEquals` instead of `opEquals` 
and `opLess` only. having so powerful `opCmp` surely opens alot way to 
abuse it.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-17 Thread ketmar via Digitalmars-d
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;

wtf?! what is that star? some trash from modem?! surely, people can write 
a function to do multiplication if they need it:

  T mul(T a, T b) { T res = a; foreach (_; 1..b) res += a; return res; }

simle and elegant. yes, it doesn't work with floats or negative `b`, but 
hey, it's for readability! if you want to process negative `b`, write 
`mulneg`!

so i'm sure that * as multiplication should be removed from the 
language.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-17 Thread weaselcat via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-17 Thread ketmar via Digitalmars-d
On Mon, 15 Jun 2015 22:06:24 +, Ola Fosheim Grøstad 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.
 
 Nah. #define does not define constants, but variable macros.
 
 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 
own name space.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-17 Thread ketmar via Digitalmars-d
On Wed, 17 Jun 2015 17:25:05 +, 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 
introduces subtle bugs to compiler, like bug #14653, for example. it's 
overlooked 'cause `alias this` is so hackish...

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-17 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-06-17 Thread via Digitalmars-d
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.




Re: version: multiple conditions

2015-06-17 Thread via Digitalmars-d

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?




Re: version: multiple conditions

2015-06-17 Thread Jacob Carlborg via Digitalmars-d

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


Re: version: multiple conditions

2015-06-17 Thread Jacob Carlborg via Digitalmars-d

On 2015-06-16 22:59, Walter Bright wrote:


#define BEGIN {
#define END }

Freedom! Freedom! Freedom!

https://www.youtube.com/watch?feature=player_detailpagev=lEOOZDbMrgE#t=163


And the current approach to operator overload is s much better, 
preventing all abuse:


struct Int
{
int a;

int opBinary(string s)(Int rhs) if (s == +)
{
return a - rhs.a;
}
}

--
/Jacob Carlborg


Re: version: multiple conditions

2015-06-17 Thread Timon Gehr via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Joakim via Digitalmars-d

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. ;)


Re: version: multiple conditions

2015-06-16 Thread Dennis Ritchie via Digitalmars-d
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.


Re: version: multiple conditions

2015-06-16 Thread via Digitalmars-d

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?




Re: version: multiple conditions

2015-06-16 Thread David Nadlinger via Digitalmars-d

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


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.




Re: version: multiple conditions

2015-06-16 Thread rsw0x via Digitalmars-d

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_detailpagev=lEOOZDbMrgE#t=163


#define PROGRAM main() BEGIN

ah, now we're getting somewhere.


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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_detailpagev=lEOOZDbMrgE#t=163


Re: version: multiple conditions

2015-06-16 Thread anonymous via Digitalmars-d

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_detailpagev=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


Re: version: multiple conditions

2015-06-16 Thread rsw0x via Digitalmars-d

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_detailpagev=lEOOZDbMrgE#t=163


#define PROGRAM main() BEGIN

ah, now we're getting somewhere.


wow, that got mangled by my touchscreen :(


Re: version: multiple conditions

2015-06-16 Thread rsw0x via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-06-16 Thread Jacob Carlborg via Digitalmars-d

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


Re: version: multiple conditions

2015-06-16 Thread Daniel Murphy via Digitalmars-d

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. 



Re: version: multiple conditions

2015-06-16 Thread Daniel Murphy via Digitalmars-d

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. 



Re: version: multiple conditions

2015-06-16 Thread Jonathan M Davis via Digitalmars-d

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


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.




Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.)


Re: version: multiple conditions

2015-06-16 Thread bitwise via Digitalmars-d
On Tue, 16 Jun 2015 16:59:36 -0400, Walter Bright  
newshou...@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_detailpagev=lEOOZDbMrgE#t=163


I take it I should just skip my next suggestion ;)

  Bit


Re: version: multiple conditions

2015-06-16 Thread Dennis Ritchie via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.




Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-16 Thread Walter Bright via Digitalmars-d

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.)


Re: version: multiple conditions

2015-06-15 Thread ketmar via Digitalmars-d
On Mon, 15 Jun 2015 17:25:07 +0900, Mike Parker wrote:

 On 6/14/2015 10:36 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
 ola.fosheim.grostad+dl...@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.

if only there is a way to define such enums from command line, akin to -
version...

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-15 Thread via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-15 Thread John Colvin via Digitalmars-d

On Monday, 15 June 2015 at 14:51:41 UTC, Jonathan M Davis wrote:

[...]


There's something refreshing about the simplicity of that :)


Re: version: multiple conditions

2015-06-15 Thread Jonathan M Davis via Digitalmars-d
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


Re: version: multiple conditions

2015-06-15 Thread ketmar via Digitalmars-d
On Mon, 15 Jun 2015 12:48:31 +, Ola Fosheim Grøstad 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.
 
 Ack… That was new to me. What is the reasoning behind this?

module processing order is not defined. so module A can try to define 
some version, and module B then try to check it, but compiler chooses to 
process module B first, and... KABOOM! compiler is free to process 
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 
matter. so if you allow versions to go over module boundaries, this 
innocent-looking code must have `abc` defined for both blocks. definetely 
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.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-15 Thread bitwise via Digitalmars-d
On Mon, 15 Jun 2015 10:58:16 -0400, John Colvin  
john.loughran.col...@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


Re: version: multiple conditions

2015-06-15 Thread via Digitalmars-d

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…





Re: version: multiple conditions

2015-06-15 Thread ketmar via Digitalmars-d
On Mon, 15 Jun 2015 21:47:26 +, Ola Fosheim Grøstad 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.
 
 Sounds like a bad excuse to me… All you need to require is that
 referenced global constants are actually… constant…

nononono. i smell #define hell from C and all the problems it brings, 
like careful ordering of #include.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-15 Thread via Digitalmars-d

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_.




Re: version: multiple conditions

2015-06-15 Thread Mike Parker via Digitalmars-d
On 6/14/2015 10:36 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
ola.fosheim.grostad+dl...@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.


Re: version: multiple conditions

2015-06-14 Thread Joakim via Digitalmars-d

On Saturday, 13 June 2015 at 21:51:43 UTC, bitwise wrote:
On Sat, 13 Jun 2015 17:29:17 -0400, Xiaoxi xia...@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 
weasel...@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.


Re: version: multiple conditions

2015-06-14 Thread weaselcat via Digitalmars-d

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.


Re: version: multiple conditions

2015-06-14 Thread ketmar via Digitalmars-d
On Sun, 14 Jun 2015 10:35:30 +, 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.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-14 Thread via Digitalmars-d

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...




Re: version: multiple conditions

2015-06-14 Thread via Digitalmars-d

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...


Re: version: multiple conditions

2015-06-14 Thread Joakim via Digitalmars-d

On Sunday, 14 June 2015 at 11:03:49 UTC, ketmar wrote:

On Sun, 14 Jun 2015 10:35:30 +, 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.


Re: version: multiple conditions

2015-06-14 Thread ketmar via Digitalmars-d
p.s. i.e. it boils down to simple thing: Walter don't like it. period. 
any rationalizing of that is pointless.

signature.asc
Description: PGP signature


Re: version: multiple conditions

2015-06-14 Thread Paulo Pinto via Digitalmars-d
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/



  1   2   >