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();
}
```
