On Monday, 24 March 2025 at 17:33:20 UTC, Richard (Rikki) Andrew Cattermole wrote:

Ok, let's put the -release thing aside for the moment.

void caller() {
	if (__ctfe) {
		callee;
	} else {
		// whatever
	}
}

void callee() @__ctfe {
}

It doesn't have to be called like that.

int caller(int x) {
  if (x < 2) {
    callee();
  } else {
    // whatever
  }
  return 0;
}
void main() {
  enum x = caller(1); // OK, we are in CTFE
  writeln(caller(2)); // OK, callee is not called
}

The condition could be as complicated as we want. It can even depend on something that is only known at run time.

You probably made a mistake unintentionally but as a result I couldn't agree more with your statement :) Sure, with callee having a @__ctfe attribute, it should be an error to call it from caller like that. And that's exactly what my implementation does. But I thought you were advocating an approach with callee having an assert(__ctfe) statement instead of @__ctfe attribute, like

void calleeWithAssert() {
    assert(__ctfe);
}

We can also make it an error to call calleeWithAssert from caller in the same way it calls callee in my example. But it is a perfectly valid and working code currently, so that will be a breaking change. That's what I'm trying to say here.

My current implementation will report an error here as well, but that we can likely fix.

On Monday, 24 March 2025 at 16:56:57 UTC, Richard (Rikki) Andrew Cattermole wrote:

import std.stdio;

string hello() in(__ctfe) => "hello world";
immutable funcTable = [&hello];
enum message = funcTable[0]();

void main()
{
    writeln(message);
}

That's a valid program, and it runs fine regardless of compiler switches. With the proposal to make assert(__ctfe) / in(__ctfe) skip codegen, you get "undefined reference to `hello'".

It absolutely matters, Ilya is right that runtime and static properties shouldn't be conflated.

On Monday, 24 March 2025 at 23:57:56 UTC, Richard (Rikki) Andrew Cattermole wrote:

You can't just skip codegen for variables, then you get 'undefined reference to funcTable' when that is used.

On Tuesday, 25 March 2025 at 00:46:15 UTC, Dennis wrote:

Anyway guys, the proposal was meant to add a property in which makes the compiler skip codegen for functions which has that property. Although it is cool that we could benefit existing code, we have been finding a lot of divergence about how that feature must be implemented without breaking code.

So, I would like to know if breaking code that uses -release is okay or we just add only the @__ctfe property so we can actually move forward.

Either way, I don't think it will benefit a lot of code since I don't know many projects out there using assert(__ctfe);, that might be really niche, even less possible that it happens to have a project which wrongly uses compile time only code which also produces a release build.

That being said, I'm more interested into alive code which keeps updating, and I really don't want to get that proposal not implemented because we can't decide :)

On Monday, 24 March 2025 at 15:25:16 UTC, Ilya wrote:

Contracts:

• Are semantically different.
• Can be switched off independently from asserts via -check.
• Don't need to parse or do semantic analysis on the bodies of functions.

On Tuesday, 1 April 2025 at 16:23:55 UTC, Atila Neves wrote:

That's all true, but contracts are still evaluated at run time, so in(__ctfe) contract doesn't guarantee we can skip codegen for such function. I've posted an example with such function being called inside a branch. Dennis posted another example, where one stores and address of such function and later uses that to call it. In both cases we can't skip codegen, even though contracts will be satisfied at run time.