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

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

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" :-)

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

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

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

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.

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.

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

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