CTFE and return statement from delegate

[Rajesh]

On Monday, 30 June 2025 at 02:21:29 UTC, WraithGlade wrote:
> 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.

Thanks Wraith, for taking the time to reply. I am new to D and 
trying to understand how delegates, CTFE, and other features 
work. When I faced the issue in one of my project, I created a 
simpler example to see if we can really use return statement 
inside a delegate in a compile time ctor.

I have already modified my project to avoid this logic, and that 
version works fine. However, I am trying to understand why this 
failure is happening. Is it a limitation of the language, a 
compiler bug, or something else?

Following is the complete code. I even tested this with [online 
compiler](https://run.dlang.io/). I tried both dmd and ldc2. 
Locally I am working with ldc2 compiler. In all the cases I am 
getting the same error, i.e.

```
Error: variable `__capture` cannot be read at compile time
onlineapp.d(27):        called from here: `Problem(0).this(1)`
auto compile_time_var = Problem(1);
```

This is full code:

```
import std;

     struct NumberType
     {
         int num;

         int opApply(int delegate(int) dg)
         {
             int result = dg(num);
             return result;
         }
     }

     struct Problem {
         int value;

         this(int val) {
             auto myType = NumberType(18);

             foreach (int number; myType)
             {
                 return;
             }
         }
     }

auto compile_time_var = Problem(1);

     void TestFunction() {
         auto runtime_var = Problem(1);
     }

     void main()
     {
         TestFunction();
     }

```