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