How does Circle's CTFE compare to D?

Johannes Riecken johannes.riecken at gmail.com
Sat Dec 4 13:53:27 UTC 2021


>> Is it likely that Circle's meta-programming also requires 
>> ten-thousands of lines of extra compiler code?

I see that Circle isn't open-source so that question seems 
impossible to answer.

On Saturday, 4 December 2021 at 09:49:39 UTC, Ola Fosheim Grøstad 
wrote:
> Circle is primarily interesting because it pushes the 
> boundaries for C++, but does it allow the execution of any C++ 
> function? I/O can make things very complicated as you either 
> have to impose a specific compilation order or use some other 
> ordering or constraining principle to avoid dependency issues 
> or feedback loops. This in turns makes it impossible to accept 
> the execution of any C++ function!

Interesting point. Do you have an example for that? Going top to 
bottom seems like a good choice.

> D's CTFE is somewhat more flexible than C++ constexpr, but C++ 
> constexpr/consteval also works as an interface specification, 
> meaning: if a function in a library is marked as compile time 
> then you can rely on it for the future and across platforms.

For functions without side effects that interface specification 
would be equivalent to adding something like `static assert f(3) 
== 9` to a compile-time function f in D?

> There are many really cute languages for writing small short 
> lived self-contained programs, but they rarely get traction. 
> (There are counter examples: PhP, Perl, …)

My understanding from the talk is that Circle can compile C++, 
too, so if Sean Baxter adds a few well-specified and easily 
understandable features in a bug-free way, then I don't see the 
lack of traction being a major issue.


More information about the Digitalmars-d mailing list