CTFE and return statement from delegate

[WraithGlade]

On Sunday, 29 June 2025 at 13:06:38 UTC, Rajesh wrote:
> This is simplified code which I am using in my project.
>
> ...

Welcome to the forum and good luck in your programming endeavors 
Rajesh.

Honestly, it isn't clear what you are even trying to do in your 
code and thus it would probably be easier for members of the 
forum to help you if you gave more context and a more complete 
and preferably directly executable example (such as a sample that 
has a working `unittest` or `main` function).

However:

The compiler's mention of `__capture` likely refers to the 
internal state of the `delegate` object you are passing into 
`opApply`. Delegates are what are called closures (or at least 
have the ability to become closures), which means they can 
implicitly capture copies or references of local variables 
located near the point of the delegate's use.

You may have omitted something from your sample code that you 
think/thought was irrelevant but is causing a variable to be 
captured by the `delegate`.

If there's even a single runtime-dependent variable in the 
`Problem` object then it could cause the whole object to become 
not computable in compile time. Compile time computation in 
programming languages sometimes have arbitrary limitations, since 
compile-time evaluation essentially hinges on the existence of an 
interpreter running in compile time alongside the compiler and 
that interpreter may not have the same abilities as the compiler 
and vice versa.

I haven't tried to run your code though, because there is 
little/no clarity on what your intent with it actually even is.

Perhaps try rewriting the relevant code in a more clear-headed 
and intentional way, patiently building it up piece by piece with 
care instead of trying to rush through it. Ask yourself each step 
of the way if you actually know what each thing does and what 
your intent is. A more *purposeful* approach is likely to clarify 
your code, which may cause the errors to drop out of whatever the 
real code is.

Aimless code has a tendency to be more erroneous than code that 
serves a real purpose because there is less anchoring your mind 
as to what you are doing and less tangible criteria to test 
against to discern when the code ever becomes "correct".

Anyway, I hope that helps.