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

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

Ok, let me take a step back. What I want to do is give users a way to say "this function is used only at compile time and you can skip codegen for it".

You say "this is already assert(__ctfe) for it, just use it". The problem with assert(__ctfe) is it doesn't guarantee codegen can be skipped. See the example above. Same goes for the suggested in(__ctfe) function contract.

Yes, we can skip codegen for a function starting with assert(__ctfe), if we replace all calls to this function with assert(__ctfe) and we are not in release build. I don't quite like it:

1. It sounds more complicated than my approach
2. More importantly, it only works in debug builds. To make it work with release builds, we need to keep assert(__ctfe) in release builds (as you suggest below). But that's a breaking change and a pretty dangerous one. Imagine you have a function f that starts with assert(__ctfe) that is almost always called under CTFE. Almost. But there is a rare code path that runs f at run time, that code path is not covered by any tests and happens roughly once a month in prod. What happens today? We hit f at run time, we run it, it might be much slower than we expected, we might even miss some deadline... but it works. If we replace calls to f with assert(false), once that code path is triggered, it just crashes.

Oh, when I say "semantics" I mean "program meaning", not refer to a semantic analysis pass in the compiler. Sorry for confusion.

Yes, I want to skip code generation. Just skipping code generation is pretty easy, I actually started with that, I can add an UDA and hack our backend (LDC) to skip codegen for marked functions. But I found that linker errors are not the nicest feedback when I was trying to make my annotations work. They usually give you a pretty good hint, yes. But there is only a function name, and it's mangled, and you have to wait until all the compilations are done, so you can run the linker.

So I thought I can do better, and make a more reasonable error message much faster with a bit of static analysis.

Yes, they could. But that's a breaking change, see above.

See above. That only works in debug build. Or we can to enable assert(__ctfe) in release, which is a breaking change.

But even putting that aside, I actually like it being a compiler error (I'm obviously biased, because of my types/static analysis background).

I was experimenting with our code base and my workflow was like this:

1. Find a good candidate (a function with lots of instances in object files but no matching symbols in the linked binary).
2. Mark it with @ctonly and look at compiler errors one by one.
3. There are essentially two cases:
   • the caller function is RT, so need to add an enum to force CTFE. This case could be caught by assert(__ctfe) if there is test coverage
   • the caller function could be CT-only itself. This will never be caught with assert(__ctfe).

No, it's a brand new attribute, with a brand new meaning. Yes, it will compile-time reject some code that will work with assert(__ctfe). But that's normal, we don't (and can't) promise that it is equivalent to assert(__ctfe).

See above, either it only works in debug or we need the breaking change.

... but you are proposing to change assert(__ctfe) semantics :)

Ok, I see two totally reasonable concerns here:

1. Tooling backward compatibility (even though LSPs usually either use the compiler directly or derive from it, I see your point here).
2. Upgrading the existing code.

Regarding 1. It doesn't have to be a full-fledged function attribute. Could be an UDA or pragma, so tools that don't know about it (pretty much everything) will simply ignore it.

Regarding 2. I don't think automatic upgrade is possible or even desirable. Since the two things are not strictly equivalent. Being said that, assert(__ctfe) is still a great signal that a function is CT-only. So, what we could do is provide a migration tool that would try adding new attributes to such functions, run the compiler, and if the compiler says "yes", we can do the change.

On Friday, 21 February 2025 at 14:04:41 UTC, Steven Schveighoffer wrote:

Yes, that's a good point, thanks.

I've already updated our internal version to use @__ctfe, it works just fine.

As I said in another reply, I think it can't (and shouldn't) be a plugin replacement for assert(__ctfe). But we can do a small migration tool.

Oh, so you are saying we will have to add an attribute (because of compiler implementation reasons), but we'll make it work as if it's an assert(__ctfe) in the first line anyway?

I don't agree here. Static check allows us to simply drop these functions, without having to rewrite call sites, it plugs naturally into existing skipCodegen implementation and it provides faster feedback, helping to set the attributes correctly. It also lets dropping more functions, think templates. If you use map!ctonly(xs), there is no point to codegen MapResult!(ctonly, xs).front for example.

The check will reject some code that could be written with asserts, that's correct. But I don't see it as a problem. It's like static vs dynamic types. You can't put a string into an int in a typed language, but in Python you can. Does it make typed languages worse? I'm not sure.

Since we are adding a new annotation, let's make it right. Such that we are absolutely sure we can omit the codegen and no surprises will happen in run time. And if someone wants to have a contrived behavior, like the one in my example, they are welcome to continue using asserts. We are not going to deprecate assert(__ctfe), right?

I honestly prefer a linker error over a run-time assert :) Sounds like a time bomb.