On 25/03/2025 4:25 AM, Ilya wrote:
> On Monday, 24 March 2025 at 14:59:17 UTC, Atila Neves wrote:
>>> However, the compiler *can* just look at the first statement in a function and see if it is an `assert(__ctfe);` and then make it an error to call it outside of CTFE.
>>
>> Even better, the compiler can also look at contracts, and I for one would rather use `in(__ctfe)` instead of `assert(__ctfe);` as the first statement. It feels less hacky and uses a feature D already has.
> 
> Contracts have the same conceptual issues as asserts: 1. they are run- time; 2. they are only enabled in debug builds. So both examples from my reply to Walter can be easily adapted to contracts.

The whole runtime vs compile time is irrelevant here.

As is weather -debug is set.

In all cases the compiler can see it was written, and it will be swapped over to a hard coded value that either will run successfully during CTFE or kill the process.

On 25/03/2025 5:54 AM, Ilya wrote:
> I'm positively sure we can't skip codegen for functions with | in(__ctfe)| contracts without breaking existing code potentially.

There is no existing code that has this and runs at runtime.

Since its false.

It asserts out at runtime.

I've been asked to make a comment of my thoughts on potentially breaking code for this feature.
Normally the policy of D is to try and not break peoples code.
This policy was created after causing a lot of problems for people over a long period of time.
It has been justified IMO.

The statement ``assert(__ctfe);`` under normal circumstances will always error at runtime if it is executed as it is equivalent to ``assert(false);``

Similar situation to ``in(__ctfe)`` with ``in(false)``

For this reason it does not matter if it errors as part of compilation or at runtime, that function is never going to be called successfully. The process will die.

If however you pass ``-release`` to the compiler, the assert will be turned off. You are removing the guard rails by doing this explicitly and understand that you could end up with bad logic running.

It is ok to take into account asserts and contracts, that would break code if functions are not available here. They shouldn't be accessible to begin with.

I want to stress that this only applies because of an opt-in switch that bypasses the protection written. If this was not set and broke code then I wouldn't be making this comment.

On 25/03/2025 6:27 AM, Ilya wrote:
> On Monday, 24 March 2025 at 17:14:57 UTC, Hipreme wrote:
>> So far, from what I've seen Atila, Walter and Rikki saying is that they actually don't care if we break people using `-release` code with code that was supposed to only run in CTFE
> 
> Uh... but that's not very nice towards the users.
> 
> It seems like a worst possible scenario: you have a proven working code, you update the compiler, you run the test suite and everything is fine, then you deploy the release version and it crashes after running for several days. One could argue that it's the user's fault they had that code path not covered by tests... But still it worked previously...

This won't change the runtime behavior, only the compile time one.

If it compiles and links, it'll do the same thing at runtime that the same source did on an earlier compiler version.

The point is it shouldn't be able to compile and link CTFE'able only code in (and with that anything that references it).

On 25/03/2025 6:16 AM, Ilya wrote:
> On Monday, 24 March 2025 at 16:56:57 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> I'm positively sure we can't skip codegen for functions with | in(__ctfe)| contracts without breaking existing code potentially.
>>
>> There is no existing code that has this and runs at runtime.
> 
> IDK if there is an existing code, since the `in(__ctfe)` pattern seems to be uncommon. But such code certainly _can_ exist. I've posted an example already: a function that is mostly called at compile time, except for the rare untested code path.
> 
> Since the code path is only triggered in release build, contracts are no-op and the code _is_ executed at runtime.

It is fine to break it, see my prior comment:

https://forum.dlang.org/post/vrs4i3$du0$1@digitalmars.com

>> Since its false.
>>
>> It asserts out at runtime.
> 
> And that's not enough. Another possibility where you can't skip codegen is the case when such function is called from a branch which is only taken in compile time. It will never be called at run time, true, so contracts hold. But the compiler won't be able to see that, so we can't skip codegen, since the caller function will still have a reference.

Unless it looks like this:

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

void callee() @__ctfe {
}
```

That ``caller`` function should not compile and link.

If it does look like that, then ``callee`` will never be referenced during codegen and all is well.