On 4/30/22 11:15, Walter Bright wrote:

> There is this paper from 2007:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
>
> which proposes extending constant folding to functions, as long as those
> functions are preceded by `constexpr` and consist of a single `return`
> statement. Recursion is prohibited. Only literal types permitted.
>
> It couldn't even replace the use of template metaprogramming to compute
> values.

Confusing that C++ proposal with D's CTFE makes me desperate. :( C++ is attempting to go one step beyond C preprocessor constants there. "Compile-time function execution" is a couple of decades beyond that simplicity.

Ali

On 4/30/22 13:14, Dukc wrote:
> On Saturday, 30 April 2022 at 20:05:14 UTC, Walter Bright wrote:

>> As to why there aren't references to D as inspiration,

Bjarne Stroustrup mentions non-C++ programming languages only when he sees failures as in "Java tried." I will never hear him mention D.

>> and no
>> references to Zortech C++'s seminal role in the early days of C++,
>> consider this:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf
>
> I can't fathom what they were thinking when they wrote that paper. The
> reasoning in it is so bad that it's an outright disgrace to the C++
> committee.

Note that the authors are just three influential people there, preempting the rest of the C++ committee from making a "mistake".

As later I learned, Andrew Sutton has been strongly against the ideas of Sean Baxter's Circle compiler as well, I started to think he may be the main author of the paper above. (The ratio of typos in that article is beyond what I am accustomed to in Bjarne Stroustrup papers.) It is unfortunate that the rest of the C++ committee accepted the "mistake" of leaving 'static if' out.

> downright hostile. You really deserved much better than that.

Not everybody has the tactfulness to accept the ideas of non-academics. So much so that they went out of their way to write a paper about it. And with a juvenile title like that...

Ali

On Saturday, 30 April 2022 at 21:59:52 UTC, Ali Çehreli wrote:
> On 4/30/22 13:14, Dukc wrote:
> > On Saturday, 30 April 2022 at 20:05:14 UTC, Walter Bright
> wrote:
>
> >> As to why there aren't references to D as inspiration,
>
> Bjarne Stroustrup mentions non-C++ programming languages only when he sees failures as in "Java tried." I will never hear him mention D.
>
> >> and no
> >> references to Zortech C++'s seminal role in the early days
> of C++,
> >> consider this:
> >>
> >> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf
> >
> > I can't fathom what they were thinking when they wrote that
> paper. The
> > reasoning in it is so bad that it's an outright disgrace to
> the C++
> > committee.
>

Huh? The paper is quite good IMHO. The tooling problems that result from `static if` are real.

On 30.04.22 23:59, Ali Çehreli wrote:
> 
>  > downright hostile. You really deserved much better than that.
> 
> Not everybody has the tactfulness to accept the ideas of non-academics.

Unfortunately that often goes both ways. :/

Also, Andrei has a PhD.

On 4/30/2022 2:59 PM, Ali Çehreli wrote:
> Note that the authors are just three influential people there, preempting the rest of the C++ committee from making a "mistake".

`static if` was eventually accepted, but with a different name and different authors.

On 4/30/22 16:10, Ola Fosheim Grøstad wrote:
> On Saturday, 30 April 2022 at 21:41:06 UTC, Ali Çehreli wrote:
>> Confusing that C++ proposal with D's CTFE makes me desperate. :( C++
>> is attempting to go one step beyond C preprocessor constants there.
>> "Compile-time function execution" is a couple of decades beyond that
>> simplicity.
>
> 2003: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1471.pdf

Good old days... I have a pre-release copy of David's templates book that he plugs in that presentation. (I used to help organize ACCU C++ meetings in Silicon Valley so I had the privilege of reading review copies of C++ books including that one).

I am very well aware of every single template metaprogramming technique that you could do with C++03 and I did use many of them in production. (Oh, I was so clever.)

But I don't remember the 'metacode' in that presentation. It must not have caught on. (?)

> An iso standard cannot absorb every single proposal, you also need all
> vendors on board, and there should be industry demand. Lots of
> "promising" ideas are thrown around, but language evolution of
> production languages should be conservative and not move forward until
> you have multiple independent implementations. There is a cost involved...
>
> What C++ does right is that they complete the features they spec out. At
> the end if the day, that is more important than absorbing cute/clever
> proposals.

Those are very wise but misplaced words. You are responding to a paragraph where I said confusing C++'s constexpr function proposal with D's CTFE gives me desperation.

Let me say it in plain words to those who may take your ISO references as proof against what I said: C++ does not have anything that comes close to D's CTFE.

Maybe you are saying that ISO will eventually produce something in the future (C++35 maybe?). I agree.

Ali

On 4/30/22 15:17, Araq wrote:

> Huh? The paper is quite good IMHO.

You have a lower bar to "papers" than I do.

The paper sounds scientific but is riddled with unscientific claims like "its adoption would be a disaster for the language", "This will make programs harder to read, understand, maintain, and
debug".

I quote: "blah blah blah". That might look good on certain type of paper but not on a scientific-sounding opinion piece like that.

The paper is written without a single piece of experience wits static if. They say "Any use of those declarations would also need to be checked by more static if statements." Poppycock! (Now, that's scientific!)

I have difficulty reading that paper because the authors do not have a single bit of self-doubt.

Their (I quote) "silly" code that mixes the preprocessor and static if is useless. Just because they could come up with ridiculous programming constructs does not constitute a counter argument to anything.

And watch this: "We have already heard suggestions of static_for and static_while. Can static_switch be far behind?" So what? What is the point in that? Is that an argument? Do the authors refute static if just because they ask that question with a smirk? I refuse it as an argument from grown ups. (The authors are from a university!)

No, re-reading the paper now (but I skipped the last parts because the first parts are more than enough for me), my opinion is the same: A bad paper.

> The tooling problems that result from
> `static if` are real.

Oh! I must have missed their point.

Ali