Re: version: multiple conditions
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
