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

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

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

On Mon, 15 Jun 2015 12:48:31 +0000, 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.

On Mon, 15 Jun 2015 10:58:16 -0400, John Colvin <john.loughran.colvin@gmail.com> wrote:

> On Monday, 15 June 2015 at 14:51:41 UTC, Jonathan M Davis wrote:
>> [...]
>
> There's something refreshing about the simplicity of that :)


Faith inspiring...if He's so sure, maybe he actually does know what he's talking about ;)

I haven't had this problem myself, but I looked at the source code for Boost once....

  Bit

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…

On Mon, 15 Jun 2015 21:47:26 +0000, 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.

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

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.

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.

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