Stroustrup's slides about c++11 and c++14

[eles via Digitalmars-d]

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

[ketmar via Digitalmars-d]

On Sat, 13 Sep 2014 20:10:53 +0000
eles via Digitalmars-d <digitalmars-d at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140913/d6464837/attachment.sig>

[Paulo Pinto via Digitalmars-d]

Post by eles via Digitalmars-d
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.

Post by eles via Digitalmars-d
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

[Joakim via Digitalmars-d]

Post by eles via Digitalmars-d
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.
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++.

[po via Digitalmars-d]

Post by Joakim via Digitalmars-d
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:(

[Joakim via Digitalmars-d]

Post by po via Digitalmars-d

Post by Joakim via Digitalmars-d
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;)

Ah, I now see that he is, since he's listed in the footnotes for
the full Stroustrup rebuttal that Walter just linked, a
researcher from Fermilab with his own static if proposal. Still
funny that this Walter was left out, although Bjarne probably
sees so many names and people, maybe they just blended together
in his mind. ;)

[deadalnix via Digitalmars-d]

Post by Joakim via Digitalmars-d

Post by po via Digitalmars-d

Post by Joakim via Digitalmars-d
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;)

Ah, I now see that he is, since he's listed in the footnotes
for the full Stroustrup rebuttal that Walter just linked, a
researcher from Fermilab with his own static if proposal.
Still funny that this Walter was left out, although Bjarne
probably sees so many names and people, maybe they just blended
together in his mind. ;)

Bjarnes simply don't want to admit that Walter is bright.

[Walter Bright via Digitalmars-d]

Post by eles via Digitalmars-d
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.
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 :-)

[Paulo Pinto via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

[...]

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

[Peter Alexander via Digitalmars-d]

On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
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.

[Timon Gehr via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
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.

[Andrei Alexandrescu via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by eles via Digitalmars-d
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.
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.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf

D offers strong evidence that static if is an enormously useful
construct. I have all respect for Bjarne as language designer,
researcher, and engineer, but the evidence suggest he called this wrong.
He is right that static if would have derailed work on concepts, because
it simply exposes them as missing the point. From that perspective N3613
is entirely politically motivated (almost all technical arguments are
bogus, and the reasonable ones are exaggerated by the fallacy of vivid
argument).

N3613 has achieved its purpose - static if will never be a part of C++,
so from that standpoint it has been successful. However, it is one of
the most vitriolic papers I have ever seen within a serious
organization, and I hope for its authors' sake they have the decency to
not be proud of it in private.

Post by Walter Bright via Digitalmars-d
C++ is adopting D features anyway. The constexpr proposals are looking a
lot like CTFE :-)

That won't be admitted, although I have reasons to believe is true. C++
intelligentsia seems to have a superiority complex with regard to D, and
that's entirely understandable.


Andrei

[bearophile via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
D offers strong evidence that static if is an enormously useful
construct.

But it's not a complete typing. The Concepts Lite are a more
principled and safer solution.
(Are Rust templates comparable to first order Concepts Lite?)

Bye,
bearophile

[Walter Bright via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d

Post by Walter Bright via Digitalmars-d
C++ is adopting D features anyway. The constexpr proposals are looking a
lot like CTFE :-)

That won't be admitted,

"parallel construction" :-)

[Paolo Invernizzi via Digitalmars-d]

On Sunday, 14 September 2014 at 01:48:51 UTC, Andrei Alexandrescu

However, it is one of the most vitriolic papers I have ever
seen within a serious organization,

I've had the same impressions...

--
/Paolo

[deadalnix via Digitalmars-d]

On Sunday, 14 September 2014 at 01:48:51 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

Post by Walter Bright via Digitalmars-d

Post by eles via Digitalmars-d
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.
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.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf

D offers strong evidence that static if is an enormously useful
construct. I have all respect for Bjarne as language designer,
researcher, and engineer, but the evidence suggest he called
this wrong. He is right that static if would have derailed work
on concepts, because it simply exposes them as missing the
point. From that perspective N3613 is entirely politically
motivated (almost all technical arguments are bogus, and the
reasonable ones are exaggerated by the fallacy of vivid
argument).

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.

Trying to implement that in a more rigorous way led me to some
"Google have no idea what you are talking about" moment. It is
fairly clear so far that I'm either very bad at research, or that
approach necessary to handle static if like construct in
languages is absolutely unresearched.

Relevant link summarizing the whole experience:
http://phdcomics.com/comics/archive.php?comicid=1727

[Andrei Alexandrescu via Digitalmars-d]

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

[bearophile via Digitalmars-d]

C++ intelligentsia seems to have a superiority complex with
regard to D, and that's entirely understandable.

D and C++ compete for a similar programming niche, but C++ is so
much widespread compared to D, that it's like comparing a blue
whale with an ant. In practice there is no real match and
competition. D is not going to replace C++ in the next few years,
and probably it will not eat a significant percentage of the C++
pie. So I think it's a good idea to have a little more
collaboration between the two language communities. Such
"superiority complex" is not going to help any one.

Bye,
bearophile

[Andrei Alexandrescu via Digitalmars-d]

C++ intelligentsia seems to have a superiority complex with regard to
D, and that's entirely understandable.

D and C++ compete for a similar programming niche, but C++ is so much
widespread compared to D, that it's like comparing a blue whale with an
ant.

Just for fun...

Blue whale mass: 190,000 kg on average (Adult)
Typical red/black ant mass: 0.003 to 0.005 grams
Ratio: 38,000,000,000x

Rough estimates for the size of the D community (based on dmd downloads)
would place it in the tens of thousands. C++ users would be over 1
million. So...

In practice there is no real match and competition. D is not going
to replace C++ in the next few years, and probably it will not eat a
significant percentage of the C++ pie. So I think it's a good idea to
have a little more collaboration between the two language communities.
Such "superiority complex" is not going to help any one.

You may be misunderstanding something. You're telling this to the wrong
people.


Andrei

[SomeDude via Digitalmars-d]

Post by bearophile via Digitalmars-d

C++ intelligentsia seems to have a superiority complex with
regard to D, and that's entirely understandable.

D and C++ compete for a similar programming niche, but C++ is
so much widespread compared to D, that it's like comparing a
blue whale with an ant. In practice there is no real match and
competition. D is not going to replace C++ in the next few
years, and probably it will not eat a significant percentage of
the C++ pie. So I think it's a good idea to have a little more
collaboration between the two language communities. Such
"superiority complex" is not going to help any one.
Bye,
bearophile

The problem is, the C++ community is unwilling to collaborate
with anyone else and this attitude is encouraged by Stroustrup.

[deadalnix via Digitalmars-d]

Post by SomeDude via Digitalmars-d
The problem is, the C++ community is unwilling to collaborate
with anyone else and this attitude is encouraged by Stroustrup.

What makes you think so ? I'm not telling you are wrong, simply
not that familiar with C++ inner circles.

[bearophile via Digitalmars-d]

Post by SomeDude via Digitalmars-d
The problem is, the C++ community is unwilling to collaborate
with anyone else and this attitude is encouraged by Stroustrup.

The C++ language has plenty of warts and unnecessary
complexities, but to me the C++ community seems normal, like
other languages communities. Usually such communities don't
collaborate a lot with other ones (I have seen the Python
community collaborate a little with the Julia community, but such
collaborations seem the exception).

Bye,
bearophile

[Walter Bright via Digitalmars-d]

Looks like this made it to reddit:

http://www.reddit.com/r/programming/comments/2hsxe2/alexandrescu_speaks_up_on_the_infamous_static_if/

[eles via Digitalmars-d]

On Tuesday, 30 September 2014 at 06:46:35 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
http://www.reddit.com/r/programming/comments/2hsxe2/alexandrescu_speaks_up_on_the_infamous_static_if/

I think the correct counter-attack is simply to write a note
showing those cases that concepts lite do not solve, at least not
as nicely as static if would have.

Eventually with D examples. It will bring audience.

[via Digitalmars-d]

Post by eles via Digitalmars-d
I think the correct counter-attack is simply to write a note
showing those cases that concepts lite do not solve, at least
not as nicely as static if would have.

It is probably not a good idea to bring more attention to it

some might end up agreeing with Stroustrup.

"static if" is a troubled construct and too close to macros to be
a good language design feature, it is in the same bag as string
mixins. "if(constexpr
)" + concepts etc better fit C++.

Post by eles via Digitalmars-d
Eventually with D examples. It will bring audience.

Yes, this a better idea. Write code examples that compare common
C++ patterns to D where D looks cleaner.

[via Digitalmars-d]

Post by eles via Digitalmars-d
I think the correct counter-attack is simply to write a note
showing those cases that concepts lite do not solve, at least
not as nicely as static if would have.

It is probably not a good idea to bring more attention to it

some might end up agreeing with Stroustrup.

"static if" is a troubled construct and too close to macros to be
a good language design feature, it is in the same bag as string
mixins. "if(constexpr
)" + concepts etc better fit C++.

Post by eles via Digitalmars-d
Eventually with D examples. It will bring audience.

Yes, this a better idea. Write code examples that compare common
C++ patterns to D where D looks cleaner.

[Timon Gehr via Digitalmars-d]

Post by eles via Digitalmars-d
...
But the surprise comes at the end (slide 57), where he also
criticizes... the static if ...
...
• 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.)

[Daniel Murphy via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d
However, as Peter points out, static if as implemented in DMD currently
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.

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.

[Walter Bright via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d
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.

[eles via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
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...

[deadalnix via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Daniel Murphy via Digitalmars-d
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

[Walter Bright via Digitalmars-d]

Post by deadalnix via Digitalmars-d
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.

[Timon Gehr via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by deadalnix via Digitalmars-d
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.)

[Timon Gehr via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d

Post by Walter Bright via Digitalmars-d

Post by deadalnix via Digitalmars-d
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.)

To elaborate a little: The following simple test case cannot be accepted
using a strategy that alternately analyses AST nodes and poisons symbols
that do not occur in certain scopes:

enum x = "enum xx = q{int y = 0;};";

struct SS{
mixin(xx);
mixin(x);
}

However, it can be given a unique meaning.

[Dicebot via Digitalmars-d]

Post by Timon Gehr via Digitalmars-d

Post by Timon Gehr via Digitalmars-d

Post by Walter Bright via Digitalmars-d

Post by deadalnix via Digitalmars-d
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.)

To elaborate a little: The following simple test case cannot be
accepted using a strategy that alternately analyses AST nodes
enum x = "enum xx = q{int y = 0;};";
struct SS{
mixin(xx);
mixin(x);
}
However, it can be given a unique meaning.

I remember deadlnix telling quite a lot of nice stories about how
this makes in sort of SDC parallelisation problematic :)

[David Nadlinger via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d
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

[David Nadlinger via Digitalmars-d]

On Sunday, 14 September 2014 at 22:58:44 UTC, David Nadlinger

Post by David Nadlinger via Digitalmars-d
I tend to run into forward referencing issues all the time
"declarative" metaprogramming

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

[Dicebot via Digitalmars-d]

On Sunday, 14 September 2014 at 22:58:44 UTC, David Nadlinger

On Sunday, 14 September 2014 at 07:35:12 UTC, Daniel Murphy

Post by Daniel Murphy via Digitalmars-d
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

Yes, this is not uncommon way to hit the wall. Separating
reflection/generation "stages" into different modules and keeping
an eye for cyclic imports seems like a best way to address it
right now in my opinion.

[deadalnix via Digitalmars-d]

I can provide first hand experience on taht one, having them
implemented in SDC.

Post by eles via Digitalmars-d
static if is a total abomination
• Unstructured, can do everything (just like goto)

True !

Post by eles via Digitalmars-d
• Complicates static analysis (AST-based tools get hard to write)

Very True !

Post by eles via Digitalmars-d
• Blocks the path for concepts

I don't think so. The 2 can cohabit.

Post by eles via Digitalmars-d
• Specifies how things are done (implementation)

I'm not sure what this one mean precisely.

Post by eles via Digitalmars-d
• Is three slightly different “ifs” using a common syntax

Yes, but i don't think this is an issue.

Post by eles via Digitalmars-d
• Redefines the meaning of common notation (such as { ... })

The meaning of {} is different depending on the construct it is
used with. That's is no different in the case of static if.

[Peter Alexander via Digitalmars-d]

Post by deadalnix via Digitalmars-d

Post by eles via Digitalmars-d
• Specifies how things are done (implementation)

I'm not sure what this one mean precisely.

The way I interpret it is that (for template constraints), they
are quite clumsy for specifying preferences between overloads,
e.g.

void foo(R)(R r) if (isInputRange!R && !isRandomAccessRange!R &&
!isSomeString!R)
void foo(R)(R r) if (isRandomAccessRange!R && !isSomeString!R)
void foo(R)(R r) if (isSomeString!R)

Would be nice to have something like this instead:

void foo(InputRange R)(R r);
void foo(RandomAccessRange R)(R r);
void foo(SomeString R)(R r);

along with a way to specify if one "concept" is more refined than
another (either explicitly or implicitly).

[Elie Morisse via Digitalmars-d]

Post by eles via Digitalmars-d
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.

[Sean Cavanaugh via Digitalmars-d]

Post by eles via Digitalmars-d
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.
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