This is simplified code which I am using in my project.

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

I am creating instance of Problem struct in runtime and compile time. Following call is giving me compilation time.

auto compile_time_var = Problem(1);

Following is the error:

Error: variable `__capture` cannot be read at compile time

Is there a restriction that I cannot call return from foreach (opApply delegate) if it is executed at compile time?

On Sunday, 29 June 2025 at 13:06:38 UTC, Rajesh wrote:

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.

On Monday, 30 June 2025 at 02:21:29 UTC, WraithGlade wrote:

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

On Sunday, 29 June 2025 at 21:56:19 UTC, 0xEAB wrote:

Thanks for your reply. It looks like a bug to me as well, but I wanted to confirm with experts if it's a known issue or a limitation before I file a bug report.

On Sunday, 29 June 2025 at 13:06:38 UTC, Rajesh wrote:

[...]

> struct Problem {
>     this(int val) {
>         foreach (int number; myType)
>             return;

[...]

Yes.

'this' is not allowed to have a 'return' (15.13.0.2) ...
and to exit a 'foreach'-loop needs a 'break' (12.11.0.6).

So the compiler should not compile that program even for runtime.

On Monday, 30 June 2025 at 14:22:47 UTC, H. S. Teoh wrote:

That is a wonderful article! I just finished reading it. Thank you for linking to it.

I wasn't previously aware of that page (being still a beginner myself) and that article further clarified my mental model of how D's compile-time features work very effectively.

I would say that anyone using D should definitely read that page once they've grasped the basics. It touches on some subtle issues one would otherwise have difficulty discerning.

It especially illuminates the fact that some things derided as D compiler bugs actually aren't, but are merely subtle.

...

Also, I wasn't aware that return isn't allowed in constructors, as the other person mentioned, so that is good to know too. I supposed it make sense, since such a return may skip some parts of the construction steps for objects, leaving them in a corrupted memory state.

On Monday, 30 June 2025 at 14:30:49 UTC, Manfred Nowak wrote:

> struct Problem {
>     this(int val) {
>         foreach (int number; myType)
>             return;

Sorry, I didn't see the reference to 15.13.0.2.

But when I read section 15.13.2 of dlang documentation, which says, "Constructors are defined with a function name of this and have no return value" my interpretation was that this prohibits returning an explicit value (like return 5;).

However, I thought a plain return; statement for control flow (like an early exit) was still allowed.

Could you please let me know if I've misunderstood this point? I appreciate your help in clarifying.