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

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.

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

On Tuesday, 30 June 2015 at 16:19:56 UTC, Jonathan M Davis wrote:
> On Tuesday, 30 June 2015 at 15:55:49 UTC, bitwise wrote:
>> On Tuesday, 30 June 2015 at 02:30:44 UTC, Walter Bright wrote:
>>>
>>> I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.
>>
>> Waiiit a minute...reading this again, it seems you are talking about writing code for a single system.
>>
>> In that case, yea, I suppose you can get by without versions. The market in multi-platform mobile apps is not something that should be ignored though.
>
> You need version blocks to distinguish between platforms (be it OSes or architectures or whatever), but code like that should be wrapped at a fairly low level, and most code shouldn't have anything like that in it. e.g. druntime has tons of version blocks, whereas Phobos has relatively few. Certainly, in general, if you're using complex expressions for versions, you should probably be rethinking how you're doing your code. I've dealt with code before that shared code across multiple products and altered its behavior via ifdefs, and it was a _disaster_. It would have been _far_ cleaner to just separate it out via libraries and section off the system-specific code such that it was contained and generally small. Once in a while, being able to && or || version identifiers like linux and FreeBSD would be nice, but on the whole, I have to agree that if you're doing much of that, it's just a recipe for disaster. I suppose that the problem is that it's just useful enough in some cases that it's annoying not to have it, but if we _did_ have it, it would be abused like there's no tomorrow.

For a concrete example from my experience, take a massively multi-platform codebase like Chromium, which is littered with #ifdef logic like this, ie #if defined(OS_CHROMEOS) || defined(OS_WIN) || defined(OS_LINUX):

http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/about_flags.cc?r1=279969&r2=279970&

It would be better if that logic weren't spread out everywhere and was abstracted out into a single place, replaced by a more specific named feature, as they've attempted to do a little here:

http://src.chromium.org/viewvc/chrome/trunk/src/build/build_config.h

Specifically, they can simply use USE_TCMALLOC instead of #if (defined(OS_WIN) || defined(OS_LINUX) || defined(OS_ANDROID)) && !defined(NO_TCMALLOC) everywhere in the source.

Yes, that means you sometimes need to check build_config.h to see how USE_TCMALLOC is defined when reading those other files, rather than always having the logic on hand.  That's the trade-off, I think it's worth it.

I believe Walter is simply trying to enforce such centralization of version logic, and I agree with him.

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

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.

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.

On Wed, 01 Jul 2015 10:16:13 +0000, Ola Fosheim Grøstad wrote:

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

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

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

Qt? AFAIK, it's C++-only, and it's widely considered to be one of the best GUI toolkits out there. Sure, having a library be in C or provide C bindings makes it more compatible with other languages, which is nice you're using another language, but the fact that someone chooses to use C++ instead of C for their library doesn't make it junk, and plenty of folks care primarily about C++, in which case, it's a non-issue.

- Jonathan M Davis

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

qt is good because it's far, _far_ more than a UI toolkit.
It's the exact opposite of something that D needs.

qt has support for XML, json, databases, audio backend, memory management system, scripting engine, web browser, etc etc
it reimplements 99% of the C++ standard library

for D, qt is overengineered junk.