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

On Sat, 13 Sep 2014 20:10:53 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

even if he crated one of the worst known abominations on the planet this still doesn't mean that he is any kind of expert in abomination analysis.

Am 13.09.2014 22:10, schrieb eles:
> This presentation:
>
> https://parasol.tamu.edu/people/bs/622-GP/C++14TAMU.pdf
>
> He criticizes C99 VLA (slide 24) as being "an abomination"


I agree with him.

C99 VLA are the typical open door to security exploits via the stack frame, that C brought upon the IT world.

To the point C11, which took security as one of the goals, has made VLA optional.

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

Well, Bjarne has his own proposal, concepts, so there is a bit of salesman speech here, I would say.

--
Paulo

On Saturday, 13 September 2014 at 20:10:55 UTC, 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 { ... })

Heh, I like how he says static if was proposed by "Walter Brown." ;)

Is it just me or did it seem like most of the stuff in those slides is already in D?  I don't follow C++.

> Heh, I like how he says static if was proposed by "Walter Brown." ;)
>
> Is it just me or did it seem like most of the stuff in those slides is already in D?  I don't follow C++.

 Walter Brown is a real person;)

 The C++ dynarray stuff was appealing to me, but it got delayed, and who knows if it will appear again:(

On 9/13/2014 1: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 { ... })
>

Yeah, well, we have many years of experience with "static if" and no apocalypse has yet happened.

The proposal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf

Bjarne's rebuttal:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf


C++ is adopting D features anyway. The constexpr proposals are looking a lot like CTFE :-)

Am 14.09.2014 00:25, schrieb Walter Bright:
> On 9/13/2014 1:10 PM, eles wrote:
>> [...]
>
>
> C++ is adopting D features anyway. The constexpr proposals are looking a
> lot like CTFE :-)

In that sense, regardless of D's future, I would say it is already a big win to have that influence over C++'s design decisions.

__
Paulo

On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright wrote:
> Yeah, well, we have many years of experience with "static if" and no apocalypse has yet happened.

Well, we are yet to define "static if" when it comes to tricky cases, i.e. cases where static ifs and mixins have interdependencies.

http://wiki.dlang.org/DIP31

Would be good to have a resolution on this.

On 09/14/2014 01:21 AM, Peter Alexander wrote:
> On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright wrote:
>> Yeah, well, we have many years of experience with "static if" and no
>> apocalypse has yet happened.
>
> Well, we are yet to define "static if" when it comes to tricky cases,
> i.e. cases where static ifs and mixins have interdependencies.
>
> http://wiki.dlang.org/DIP31
>
> Would be good to have a resolution on this.

Note that DIP31 is quite weak because 'order of appearance in the source' is not well-defined for constructs appearing in files that cyclically import each other and the 'poison mode' is IMO enabled too often.

However, I get quite promising results using explicit dependency tracking, running analysis until it is stuck on symbol lookup and then poisoning the symbols in the topmost strongly connected component of the dependency graph. I still need to find a good way to make nested template instantiation fast enough with this approach though.

On 09/13/2014 10:10 PM, eles wrote:
> ...
> But the surprise comes at the end (slide 57), where he also
> criticizes... the static if ...
>
> Are those points valid?:
> ...
> • 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 { ... })

In D, { ... } has this other meaning even without static if and I would say similar syntax rather than common syntax and leave out the pointless reference to goto.

Otherwise, yes. In exchange you get static if. :o)

However, as Peter points out, static if as implemented in DMD currently has some serious issues:

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

This code is ambiguous: It could define either x or y.

If the two static if's are defined in different modules that import each other, then the order those modules are passed to DMD on the command line can influence which of x or y ends up being defined.

The problem is that DMD does not seem to have a coherent way of resolving dependencies. (My own project does not compile with versions of DMD after 2.060, and even with 2.060, I had to move code around randomly. I think it will be easily fixed to compile again only when analysis dependency management is fixed in a good enough way.)