On 9/14/14, 3:42 AM, deadalnix wrote:
> To be fair, the way it is implemented right now is a hack, and it is not
> C++ standard grade definition. Not even remotely close.

That hasn't been a problem. There are many hacks that have been standardized in C++.

Andrei

On 9/14/2014 12:35 AM, Daniel Murphy wrote:
> I do acknowledge this is a problem, but I am yet to run into it in actual D
> code.  Most of my static ifs are either inside templates, inside functions, or
> are being used to bypass version's limitations.

A similar problem once existed in the druntime, which caused a bunch of head-scratching nastiness. The problem was the person who wrote it was trying to make an import context-dependent, i.e. behave differently depending on how it was imported.

I replaced the offending logic with straightforward code, but it does expose this dependency problem with static if.

The compiler should detect these sorts of things and reject them.

On Sunday, 14 September 2014 at 20:21:51 UTC, Walter Bright wrote:
> On 9/14/2014 12:35 AM, Daniel Murphy wrote:

> The compiler should detect these sorts of things and reject them.

I agree. Let's not forget that the complication of C and C++ started with exactly such "small and negligible" inconvenients that latter proved more and more difficult to solve...

On Sunday, 14 September 2014 at 20:21:51 UTC, Walter Bright wrote:
> On 9/14/2014 12:35 AM, Daniel Murphy wrote:
>> I do acknowledge this is a problem, but I am yet to run into it in actual D
>> code.  Most of my static ifs are either inside templates, inside functions, or
>> are being used to bypass version's limitations.
>
> A similar problem once existed in the druntime, which caused a bunch of head-scratching nastiness. The problem was the person who wrote it was trying to make an import context-dependent, i.e. behave differently depending on how it was imported.
>
> I replaced the offending logic with straightforward code, but it does expose this dependency problem with static if.
>
> The compiler should detect these sorts of things and reject them.

If that is really a concern, please consider commenting on http://wiki.dlang.org/DIP31

On 9/14/2014 2:48 PM, deadalnix wrote:
> If that is really a concern, please consider commenting on
> http://wiki.dlang.org/DIP31

I haven't thought it through, but the DIP looks like a good idea.

It should add the test case in this thread,

  static if(!is(typeof(x))) enum y=2;
  static if(!is(typeof(y))) enum x=1;

as being something that is detected and rejected by the compiler.

Essentially, anything that is order-of-evaluation dependent should be detected and rejected.

On Saturday, 13 September 2014 at 20:10:55 UTC, eles wrote:
> Are those points valid?:
>
> static if is a total abomination
> • Unstructured, can do everything (just like goto)
> • Complicates static analysis (AST-based tools get hard to write)
> • Blocks the path for concepts
> • Specifies how things are done (implementation)
> • Is three slightly different “ifs” using a common syntax
> • Redefines the meaning of common notation (such as { ... })

The lack of « something like static if » in C++ and his opposition to it (which dates back from many years ago) is what made me search for better languages and discover D.

C++ has only half-assed metaprogramming limited to types, and the lack of static if has forced me so many times to rewrite very similar code from one function to another.

With D I can have a « function skeleton » and avoid all redundancies with static if. Plus mixins expand enormously on the C preprocessor (although AST macros would be even better).


IMHO it's all good for D, full-featured metaprogramming is a killer feature and can save a great amount of time and headaches. The more backwards C++ chooses to remain the faster alternatives will grow.

On Sunday, 14 September 2014 at 07:35:12 UTC, Daniel Murphy wrote:
> I do acknowledge this is a problem, but I am yet to run into it in actual D code.  Most of my static ifs are either inside templates, inside functions, or are being used to bypass version's limitations.

I tend to run into forward referencing issues all the time "declarative" metaprogramming, i.e. when generating some code based on existing symbols and their attributes (e.g. serialization, RPC, …). Manu IIRC also has some related war stories to tell.

Granted, it's not the directly the same as two ifs next to each other conflicting (you mostly get dependencies via __traits(allMembers, …) and so on), but whatever forward reference resolution mechanism we choose must be able to handle both the same.

David

On Sunday, 14 September 2014 at 22:58:44 UTC, David Nadlinger wrote:
> I tend to run into forward referencing issues all the time "declarative" metaprogramming

Whoops, a "with"/"when doing" went missing there.

On 9/13/2014 3:10 PM, eles wrote:
> This presentation:
>
> https://parasol.tamu.edu/people/bs/622-GP/C++14TAMU.pdf
>
> He criticizes C99 VLA (slide 24) as being "an abomination"
>
> But the surprise comes at the end (slide 57), where he also
> criticizes... the static if as being "a total abomination". Well, this
> is D, I told myself.
>
> Are those points valid?:
>
> static if is a total abomination
> • Unstructured, can do everything (just like goto)
> • Complicates static analysis (AST-based tools get hard to write)
> • Blocks the path for concepts
> • Specifies how things are done (implementation)
> • Is three slightly different “ifs” using a common syntax
> • Redefines the meaning of common notation (such as { ... })
>

Its a downright cute and cuddly abomination to have as opposed to the one that exists in the world of #define and its minions #if/#ifdef/#elif/#if defined()/#else/#endif

On 09/15/2014 12:38 AM, Walter Bright wrote:
> On 9/14/2014 2:48 PM, deadalnix wrote:
>> If that is really a concern, please consider commenting on
>> http://wiki.dlang.org/DIP31
>
> I haven't thought it through, but the DIP looks like a good idea.
>
> It should add the test case in this thread,
>
>    static if(!is(typeof(x))) enum y=2;
>    static if(!is(typeof(y))) enum x=1;
>
> as being something that is detected and rejected by the compiler.
>
> Essentially, anything that is order-of-evaluation dependent should be
> detected and rejected.

(It is furthermore also important that most programs that are not dependent on evaluation order are still accepted.)