I certainly would prefer ``assert(__ctfe);``.

It would opt-in existing code (correctly). That alone is a pretty convincing argument.

Not having to learn additional things, and having what appears like it should work work is always a good design choice.

On Thu, Sep 28, 2023 at 04:35:10PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> I certainly would prefer ``assert(__ctfe);``.

+1.

Maybe also detect code of the following form?

	auto func(Args args) {
		if (__ctfe) {
			...
		}
		else assert(0);
	}


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

On Thursday, 28 September 2023 at 03:35:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I certainly would prefer ``assert(__ctfe);``.
>
> It would opt-in existing code (correctly). That alone is a pretty convincing argument.
>
> Not having to learn additional things, and having what appears like it should work work is always a good design choice.

The assert hack is useful but limited.  It will not fail at compile time, will not prevent all code/symbol generation, will not enable compile time understanding that the function is restricted to use at compile time (if that's useful apart from the other ...).

I think we can do better in this area (eliminating/controlling spew to the linker) and in target enumeration generally {CT, generic CPU, CPU specializations, dcompute variants} but not without quite a bit more effort for the generality and/or soup-free analysis.

On 28/09/2023 5:58 PM, Bruce Carneal wrote:
> The assert hack is useful but limited. It will not fail at compile time, will not prevent all code/symbol generation, will not enable compile time understanding that the function is restricted to use at compile time (if that's useful apart from the other ...).

This proposal (should this PR changed to it) would restrict that function to CTFE only.

On 28/09/2023 6:04 PM, ryuukk_ wrote:
> Why couldn't the compiler already guess this?
> 
> To me a simple static analysis would be enough and better, or is it too slow? time saved not generating what's not used could offset time spent on the analysis?

When you do multi-step builds (which are common), this would result in link failures. Since you don't have all the code, you can't do any analysis without failures being possible. It would make druntime and Phobos fail to link correctly with a giant list of missing symbols.

On Thursday, 28 September 2023 at 03:35:10 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I certainly would prefer ``assert(__ctfe);``.
>
> It would opt-in existing code (correctly). That alone is a pretty convincing argument.
>
> Not having to learn additional things, and having what appears like it should work work is always a good design choice.

That would suffer all the same problems that `pragma(inline)` as a statement has. The information that a function should not be emitted (or should be inlined) is an outward facing attribute of that function, not an internal facing attribute. It will screw up .di generation, and make separate compilation more difficult. You also can't flip a switch to change if from not emitting to emitting it if you want to debug the function at runtime.

On 28/09/2023 8:36 PM, Nicholas Wilson wrote:
> It will screw up .di generation, and make separate compilation more difficult.

No not really, think about the constraints of CTFE.

You can't elide a function body which is to be used from CTFE. Since you have to have the function body to CTFE it.

So where the annotation exists, doesn't matter too much.