www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Stroustrup's slides about c++11 and c++14

reply "eles" <eles215 gzk.dot> writes:
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 { ... })
Sep 13 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Sep 13 2014
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
Sep 13 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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++.
Sep 13 2014
parent reply "po" <yes no.com> writes:
 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:(
Sep 13 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Saturday, 13 September 2014 at 21:54:19 UTC, po wrote:

 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. ;)
Sep 14 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 14 September 2014 at 07:42:14 UTC, Joakim wrote:

 On Saturday, 13 September 2014 at 21:54:19 UTC, po wrote:

 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.
Sep 14 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-)
Sep 13 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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
Sep 13 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Sep 13 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 13 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/14, 3:25 PM, Walter Bright wrote:

 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


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.


 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
Sep 13 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 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
Sep 13 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/13/2014 6:49 PM, Andrei Alexandrescu wrote:

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


 That won't be admitted,


"parallel construction" :-)
Sep 13 2014
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Sunday, 14 September 2014 at 01:48:51 UTC, Andrei Alexandrescu 
wrote:

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


I've had the same impressions...

--
/Paolo
Sep 14 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 14 September 2014 at 01:48:51 UTC, Andrei Alexandrescu 
wrote:

 On 9/13/14, 3:25 PM, Walter Bright wrote:

 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


 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
Sep 14 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 14 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 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
Sep 15 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/15/14, 11:17 AM, bearophile wrote:

 Andrei Alexandrescu:


 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
Sep 15 2014
prev sibling parent reply "SomeDude" <lolilol mytrashmail.com> writes:
On Monday, 15 September 2014 at 18:17:37 UTC, bearophile wrote:

 Andrei Alexandrescu:


 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.
Sep 29 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 30 September 2014 at 00:02:49 UTC, SomeDude wrote:

 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.
Sep 29 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:


 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
Sep 29 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Looks like this made it to reddit:

http://www.reddit.com/r/programming/comments/2hsxe2/alexandrescu_speaks_up_on_the_infamous_static_if/
Sep 29 2014
parent reply "eles" <eles eles.com> writes:
On Tuesday, 30 September 2014 at 06:46:35 UTC, Walter Bright 
wrote:

 Looks like this made it to reddit:

 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.
Sep 30 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 30 September 2014 at 07:04:39 UTC, eles wrote:

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


 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.
Sep 30 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Sep 13 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Timon Gehr"  wrote in message news:lv2mgv$qcq$1 digitalmars.com...


 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.


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.
Sep 14 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 14 2014
next sibling parent "eles" <eles215 gzk.dot> writes:
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...
Sep 14 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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
Sep 14 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 14 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Sep 14 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/15/2014 04:53 AM, Timon Gehr wrote:

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


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.
Sep 14 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 15 September 2014 at 03:10:08 UTC, Timon Gehr wrote:

 On 09/15/2014 04:53 AM, Timon Gehr wrote:

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


 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.


I remember deadlnix telling quite a lot of nice stories about how 
this makes in sort of SDC parallelisation problematic :)
Sep 17 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Sep 14 2014
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
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.
Sep 14 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 14 September 2014 at 22:58:44 UTC, David Nadlinger 
wrote:

 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


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.
Sep 17 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
I can provide first hand experience on taht one, having them 
implemented in SDC.

On Saturday, 13 September 2014 at 20:10:55 UTC, eles wrote:

 static if is a total abomination
 • Unstructured, can do everything (just like goto)


True !

 • Complicates static analysis (AST-based tools get hard to 
 write)


Very True !

 • Blocks the path for concepts


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

 • Specifies how things are done (implementation)


I'm not sure what this one mean precisely.

 • Is three slightly different “ifs” using a common syntax


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

 • 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.
Sep 14 2014
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 14 September 2014 at 09:42:28 UTC, deadalnix wrote:

 • 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).
Sep 14 2014
prev sibling next sibling parent "Elie Morisse" <syniurge gmail.com> writes:
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.
Sep 14 2014
prev sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
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
Sep 14 2014