On Sunday, 17 October 2021 at 21:17:43 UTC, Paulo Pinto wrote:
>
> It is useless for the community to whine who did it first, because it won't increase its audience.

Nobody did that, you were the one.. https://forum.dlang.org/post/hbqsocypigbjefuwqpnm@forum.dlang.org

On Sunday, 17 October 2021 at 21:11:34 UTC, max haughton wrote:
> On Sunday, 17 October 2021 at 19:18:25 UTC, Walter Bright wrote:
>> On 10/17/2021 3:03 AM, Ola Fosheim Grøstad wrote:
>>> [...]
>>
>> You're confusing data flow analysis and function inlining with ctfe. I know how data flow optimizers work, I was the first to implement one for DOS compilers in the 80s.
>>
>> [...]
>
> https://gcc.godbolt.org/z/jr5W6rY1W
>
> If I read you correctly, gcc circa '06 could do what you describe. Or do you mean in windows land?

put the square function in another compilation unit (i.e. its source is not available), and see if it can optimize it. ;-)
That's the difference between CTFE and inlining.

On Monday, 18 October 2021 at 06:48:25 UTC, Patrick Schluter wrote:
> put the square function in another compilation unit (i.e. its source is not available), and see if it can optimize it. ;-)
> That's the difference between CTFE and inlining.

There were C/C++ compilers that did whole program optimization (IR) in the 90s, but the key difference between optimization of function calls and compile time function evaluation is when the evaluation affects the type. (enum being one simple example, static array length being another). In this case it has to be required by the language, so it is no longer an implementation detail.

On Monday, 18 October 2021 at 01:01:53 UTC, russhy wrote:
> On Sunday, 17 October 2021 at 21:17:43 UTC, Paulo Pinto wrote:
>>
>> It is useless for the community to whine who did it first, because it won't increase its audience.
>
> Nobody did that, you were the one.. https://forum.dlang.org/post/hbqsocypigbjefuwqpnm@forum.dlang.org

Wrong, it was in response to "About 50% of it is inadvertent praise for D.", because naturally for some people when any language has something that somehow resembles D, it was copied from D, regardless of prior art.

And apparently some are quite touchy to facts.

On Monday, 18 October 2021 at 11:22:10 UTC, Paulo Pinto wrote:
> Wrong, it was in response to "About 50% of it is inadvertent praise for D.", because naturally for some people when any language has something that somehow resembles D, it was copied from D, regardless of prior art.

There are two twin siblings. One is praised for having good looks and good grades. This praise is described as "50% inadvertent praise for the the other twin". Do you conclude that one child stole other's looks or grades?

You might if you had an axe that needed grinding. But most people would get the joke: the other twin's grades are poor.

If you'd watched any amount of the presentation before replying, you'd see there's lots of praise for things that can't even be "copied from D", like praise for a fast compiler, and there's also lots of praise that doesn't apply to D at all. It's about 50% unintentional praise for D, which I think makes it more of interest to a D audience. Do I need add a disclaimer any time this happens? "Here's a cool presentation about Kotlin. About 20% of it is inadvertent praise for D. My lawyers have advised me to include this addendum to this post: Common Lisp was standardized in 1994 with closures."

> And apparently some are quite touchy to facts.

Part of your 'facts' are accusing Walter of simply lying about his memories of ctfe and its reception, as if everyone in all programming communities was obliged to be constantly aware of every innovation anywhere in computing. The average compiler developer, shown Forth, was going to say "well, yeah, if you have a single pass compiler and are constantly compiling into an interactive environment, I guess you could get compile-time interaction this way, but I don't see how I could do anything like that."

On Monday, 18 October 2021 at 11:42:47 UTC, jfondren wrote:
> Part of your 'facts' are accusing Walter of simply lying about his memories of ctfe and its reception, as if everyone in all programming communities was obliged to be constantly aware of every innovation anywhere in computing. The average compiler developer, shown Forth, was going to say "well, yeah, if you have a single pass compiler and are constantly compiling into an interactive environment, I guess you could get compile-time interaction this way, but I don't see how I could do anything like that."

Dynamic languages can in general support "compile time function evaluation". One strategy is to run a program then force a core-dump and use a core-dump loader as the executable. Making a point of ctfe only makes sense in the context of C++ type construction. In that regard it is an improvment (over using C++ templates in a functional programming manner).

On Sunday, 17 October 2021 at 16:10:56 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 17 October 2021 at 14:47:15 UTC, Imperatorn wrote:
>> How would you write it in C++ without modifying the stdlib
>
> Well, you can't because pow() is not known at compile time (in a portable way). It is only known, in the general case, when executed. If you allow it to be evaluated at compile time you risk a compiletime pow(x,y) value to be different from a runtime pow(x,y) value even though the parameters are exactly the same. Which could lead to bugs (like comparing for equality).

We can leave floating point out of the discussion. This is integer arithmetic.

— Bastiaan.

On Monday, 18 October 2021 at 14:23:07 UTC, Bastiaan Veelo wrote:
> We can leave floating point out of the discussion. This is integer arithmetic.

std::pow() is floating point: «If any argument has integral type, it is cast to double.»

On Monday, 18 October 2021 at 15:39:32 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 18 October 2021 at 14:23:07 UTC, Bastiaan Veelo wrote:
>> We can leave floating point out of the discussion. This is integer arithmetic.
>
> std::pow() is floating point: «If any argument has integral type, it is cast to double.»

Still. The question was not about pow 😅

It was about how poor C++ is doing stuff at compile time in general.

On Monday, 18 October 2021 at 15:45:18 UTC, Imperatorn wrote:
> Still. The question was not about pow 😅

Choose a better example then. :-)

> It was about how poor C++ is doing stuff at compile time in general.

There are many facets of C++. One is that the original C++ compilation model is built around hand-tuned separate compilation to handle very large projects. Most projects are not all that large, certainly none of my C++ projects. And what was large in the 90s is different from what is considered large now. So, that is the downside of using languages like C++ which has a long history. Although, I think this is a weakness that affects D too.

Anyway, most of the stuff I want to do at compile time in C++, can be done as constexpr. Although for source generation I sometimes prefer to use Python to generate C++ source as I find it more readable to have explicit code rather than meta code in the source.