On Tuesday, 11 March 2025 at 15:59:08 UTC, Ilya wrote:

Sorry about that. That's an oversight. It's been open for a while. But if you choose to write a DIP, the new process is to post the first draft to the DIP Development forum for community feedback, followed by as many draft reviews as necessary, before submitting a PR.

I ask people to notify me before they initiating the first draft. Most people so far have ended up skipping that step. The reason I ask is so that I can ensure that Walter and/or Atila have provided initial feedback in the idea forum before you invest the time on the draft.

I see in this thread that Walter replied to a comment, but neither he nor Atila has provided any feedback on the proposal. I'll ping them and ask them to chime in. That may influence your decision to proceed with a draft.

On Sunday, 16 March 2025 at 07:05:50 UTC, Walter Bright wrote:

Yes, this is exactly about improving compile time (allowing to skip codegen for a templated CT-only function with ~20K instantiations does make a difference).

int func() { assert(__ctfe); ... }

Well, that's a technical issue that I'm sure could be solved one way or another. There is however a more important issue with the way asserts work.

We can, but it can break existing code. I've posted example in this thread already. Let's say we have a function starting with assert(__ctfe).

1. It could be called from a branch that is only reached inside CTFE, compiler won't be able to figure this out, and that will be a compile-time error.
2. It could be called at runtime, but very rarely, and there are no tests triggering that behavior. So it works perfectly, since assert(__ctfe) is only reached either inside CTFE or in release code, with the assert compiled out. So the code that previously worked is a compile-time error now. That's arguably a good one, since clearly it just slipped into release version due to runtime nature of asserts. But I still feel bad about breaking previously working code.

@ctonly int func() { ... }

int func() { assert(__ctfe); ... }

Many people suggested to use @__ctfe instead of @ctonly, that can be parsed with unmodified compiler, so no new syntax.

But that part is not possible without breaking existing programs. Asserts happen at run-time, we simply can't precisely predict at compile time if they will trigger or not, so with a compile time check we have to approximate, meaning some existing code that works fine at run-time will result in compile time error.

That's why I'm proposing not to squash the two things together, keep the existing run time behavior of assert(__ctfe) and add a brand new compile time behavior for @__ctfe attribute.

And while I strongly believe we generally can't piggyback on assert(__ctfe) as a "skip codegen" flag, it still provides a very strong signal that a function is likely CT-only. So once the new attribute thing works, we could provide users with a tool that tries adding @__ctfe attribute to functions with assert(__ctfe) and if it compiles, the change could be committed safely. That would simplify the migration of existing code heavily relying on assert(__ctfe).

What do you think?

On Sunday, 16 March 2025 at 16:57:44 UTC, Walter Bright wrote:

Yes, and that's exactly the problem. With the existing assert semantics, assert(__ctfe) as the first statement of a function does not provide a guarantee that this function could be omitted from codegen. So we can't use assert(__ctfe) as a CTFE-only marker.

On Sunday, 16 March 2025 at 19:19:03 UTC, Walter Bright wrote:

Ok, let me repeat it once again. I can think of two scenarios:

1. A function with assert(__ctfe) is called behind a guarding condition. For example:

   void f() {
     assert(__ctfe);
   }
   int g(int x) {
     if (x < 5) {
        f();
     }
     return x;
   }
   void main() {
     enum x = g(3); // OK, we are in CTFE
     writeln(g(6)); // OK, f is not called
   }
   

   Skipping codegen of f will result in a linker error, since g still references f, even though it's never called outside of CTFE. Steven suggested replacing calls to f with assert(__ctfe) (or a stricter version of it, that would also fire in release build), but it doesn't cover the second case...

2. A function with assert(__ctfe) is occasionally called outside of CTFE, but it's a rare and untested execution path:

   int f(int x) {
     assert(__ctfe);
     return x + x;
   }
   void is_called_once_a_month_and_not_covered_by_tests(int x) {
     int x = f(x); // this happens at runtime, but rarely and is not covered by tests, so it only ever executed with release build and assert doesn't fire
   }
   void covered_by_test() {
     enum v = f(10); // other callers of `f` call it under CTFE.
   }
   

   In this case just skipping codegen of f is arguably better: it will break the build with a linker error, but at least people would look at it, find out the cause and fix it. Replacing calls to f with assert(__ctfe) will make the code break at run-time after the rare codepath is triggered, likely after running for a long time.