On Thursday, 20 February 2025 at 15:50:33 UTC, Steven Schveighoffer wrote:

void foo() {
   assert(__ctfe);
}

Yes, I've seen that. But did it go anywhere? I think on the thread I've found there are some discussions with no conclusion.

I also found another proposals that are suggesting introducing a new attribute (like I do). But there are also no sign of any activity.

I do see a value in not requiring any language changes, but:

1. I'm concerned about doing compile time things based on an assert, which is a run time thing.
2. I think making an attribute is a bit clearer. Like, asserts are supposed to only affect debug builds (well, except for assert(false)), but I want this new functionality to work in release builds too. There is nothing that stops me from implementing that, but I don't like that assert's meaning gets another exception.

I agree with the point that existing code could immediately benefit from it. That's great. But there is also the second side of this medal: that could also render some existing code non-compilable. How come? Asserts are run-time, what I'm proposing is a static check, so compile time. Static checks are usually either unsound or incomplete. I prefer to stay on the sound side, so it's doomed to be incomplete, meaning it will reject some examples that are working fine with run-time asserts. Imagine this:

int ctonly(int x) {
  assert(__ctfe);
  return x+1;
}
int f(int v) {
  if (v < 10) {
    return ctonly(v);
  } else {
    return smth_runtime(v);
  }
}
void main() {
  enum x = f(9); // that's fine, CTFE
  auto y = f(10); // that's also fine, f() doesn't call ctonly()
}

This works with runtime assert, but will be rejected by the check.

That won't work the same way assert(__ctfe) works today, see the example above, so you are proposing to change the semantics of assert(__ctfe).

I think it's better to require the user to be explicit about that, otherwise we may end up with skipping code generation of main :) The only exception is when such function is passed as a template parameter, in this case I believe we need to add some basic inference to make it usable in practice.

Yeah, we can take the shortcut in the implementation and only look at the first statement, but I'm more concerned about changing the semantics.

Why does it have to be this form?

On Thursday, 20 February 2025 at 15:51:51 UTC, Paul Backus wrote:

Thanks for the pointer, I haven't used consteval in C++, that seems relevant indeed.

On Thursday, 20 February 2025 at 17:42:25 UTC, Ilya wrote:

void foo() {
   assert(__ctfe);
}

It has not gone anywhere, but if we were to consider a language change, I'd want to evaluate whether this is a better option, since it's a de-facto standard.

At the root this is code generation. Do you want to generate code or not? Semantic already has to run for CTFE.

assert(__ctfe) (and assert(!__ctfe)) could be in the same vein as assert(0) -- that is, it always evaluates even in release builds.

int ctonly(int x) {
  assert(__ctfe);
  return x+1;
}
int f(int v) {
  if (v < 10) {
    return ctonly(v);
  } else {
    return smth_runtime(v);
  }
}
void main() {
  enum x = f(9); // that's fine, CTFE
  auto y = f(10); // that's also fine, f() doesn't call ctonly()
}

Yes, this is a problem with the idea to make it a compiler error.

However, the compiler still does not have to generate code for ctonly, even if we don't make it an error. It can just replace the call with an assert(__ctfe) (or one that produces a nice message).

Yes, you are right. Then again, your attribute has the same issue, no?

I think with replacing any runtime calls to a ctfe-only function with an assert, we have basically the best that can be had.

In general we should prefer solutions that don't require changing syntax/semantics:

• no need to update IDEs/LSP
• no need to change any semantics
• no new attributes to worry about
• if we hook onto a de-facto standard, then existing code is upgraded automatically.

-Steve

On Thursday, 20 February 2025 at 19:44:37 UTC, Steven Schveighoffer wrote:

void foo() {
   assert(__ctfe);
}

Paul Backus pointed out on discord, there is a very large problem with this mechanism:

importing a file with a function that is not a template nor an auto function means the semantic is skipped for that function. This means it would be impossible to know that this function is ctfe-only. The only other solution there is to semantic every function, which basically negates any wins we get from not optimizing these functions.

So reading all the responses here, my impression is:

1. I think it's a necessary idea to have an attribute if we want this feature. I like using @__ctfe as this requires no new syntax, and actually already compiles (it just doesn't do the thing expected). What remains to be seen is if we can hook this properly. @__ctfe becomes @(true) currently. If not, then a new attribute is trivial to add to core.attributes.
2. If we are going to have a mechanism to flag that code generation should be avoided, it would be good to also do this for functions that begin with assert(__ctfe). This at least helps with existing uses of that mechanism.
3. I don't agree with the compiler errors for all uses of ctfe-only functions at runtime. As you pointed out, this can be valid for cases. I don't think it's worth the headache, and I have learned in the past not to pre-optimize for rule following especially in generic code. Just let the thing happen as it would.
4. To that end, calling a known ctfe-only function should result in an appropriate assert(false, "cannot call ctfe-only function blahblah at runtime") when doing code generation instead of the call to a non-existent function that has a linker error.

-Steve