Hi,

import std;

void main() {
    int val = 4;
    enum prog = q{
        (){ val += 1; return val; }()
    };
    //mixin(prog); //
    auto dummy = mixin(prog); //Must capture the return value, otherwise it hallucinates EOF.
    writeln(val);
}

When uncommenting mixin(prog);
It gives

Error: found `End of File` when expecting `;` following expression
expression: `()
{
    val += 1;
    return val;
}
()`

It happens only when NOT capturing the result of the mixed in evaluated lambda function.
I've noticed this since LDC 1.41

Is this a feature or a bug? :D
Is there a way to make this processing_and_optional_returning thing better?

Use case: The purpose of this is that I can put knobs and sliders into my IDE, nested in the source code text that work on a value reference: It synchronizes the value between the running program and the IDE. Underneath the slider there is a mixin() expression. The weird problem only happens when I DON'T capture the result of that mixin() expression. Sometimes I put a value display around the slider, that reads its value, but sometimes that's not needed. Now in that latter case I get a scary End Of File error.

Note: It doesn't matter it I use lambda or a normal function. The error is triggered when I don't capture a return value on the membrane of a string mixin() expr.

Thank You in advance!

On Friday, 12 September 2025 at 08:36:42 UTC, realhet wrote:

import std;

void main() {
    int val = 4;
    enum prog = q{
        (){ val += 1; return val; }()
    };
    //mixin(prog); //
    auto dummy = mixin(prog); //Must capture the return value, otherwise it hallucinates EOF.
    writeln(val);
}

Error: found `End of File` when expecting `;` following expression
expression: `()
{
    val += 1;
    return val;
}
()`

Hi realhet,

I can explain what happens here.

When you write auto x = mixin(bla);
The mixin it parsed as an expression.
b/c there can only be an expression after the =.
However when you don't do that the mixin is parsed as a statement, after which a ; is expected and mandatory.
putting a ; into the string generated by prog should fix that.

On Friday, 12 September 2025 at 08:44:47 UTC, Stefan Koch wrote:

When I turn the string mixin into a statement by putting a ; at its end, the

enum bla = (){return 4;}();

mixin(bla); Case works perfectly. It just drops its return statement;

But now the expression variant drops an error:

auto x = mixin(bla);

Error: unexpected token `;` after call expression
	while parsing string mixin expression

So my problem is that before 1.41 both versions went fine with the expr mixin template.

enum bla = (){return 4;}();;
mixin(bla); //Compiles, drops the return value
auto x = mixin(bla); //Compiles, stores the return value in variable x

At this point of understanding, I can solve this in a manual way by using 2 string mixins: an expression mixin and a statement mixin. I'm only a bit sad, that in the past it was fully automatic.

I think back then compiler verified it the mixin is a statement or an expression at a later state.
But now as you said, it expects one of them by checking the place of mixin insertion:

• if it finds an =, then it must be a mixin expression. <- this expectation is valid
• if it does not find an =, then it must be a mixin statement. <- Now this is bad, because xxx; xxx can be BOTH a mixin statement and a mixin expression(with side effects and unused return value).

(BTW, I was a bit angry, but I really should not! This is precious learning :D)

On Friday, 12 September 2025 at 08:36:42 UTC, realhet wrote:

It is a bug in your code.

Change line 6 to

        (){ val += 1; return val; }();

After the added ; it should work as expected.

On Friday, 12 September 2025 at 08:36:42 UTC, realhet wrote:

You will have to start writing much weirder code than this to find compiler bugs in D because when a bug is fixed, a new test is created to make sure it doesn't regress. Surface-level features are usually pretty well tested unless they're literally brand new.

Here are some fun bugs I've found:

• https://github.com/dlang/dmd/issues/21627
• https://github.com/dlang/dmd/issues/20850

The most fun is when the compiler crashes, like here

On Friday, 12 September 2025 at 09:55:01 UTC, IchorDev wrote:

Yea, I don't think I dare to do such crazy things, like an lambda in an UDA :D (But now I can't unlearn what I've learned, haha)

I guess it is a feature, a restriction that protects us.

The feature is that the compiler expects the mixin to be this or that, and not parse any type of mixin (statement or expression), and automatically decide what to do with it later.

But in my perspective this is a problem, and the only way I can solve is with more complexity. Basically I will have 2 set of knobs and sliders (any UI components are supported, it's just an example) and I have to choose if I want to use the expression or the statement variant. Or I use more complexity and let the IDE choose the right on when saving the source code text. It can detect the = just like the new compiler.

Here's a clip showing the problem: youtu.be/6b_kvZL6qjE

On Friday, 12 September 2025 at 09:17:10 UTC, realhet wrote:

Error: unexpected token `;` after call expression
	while parsing string mixin expression

I don't think so, according to run.dlang.org:

void main() {
  enum bla = `(){return 4;}();`;
  mixin(bla);
  auto x = mixin(bla);
}

Up to      2.078.3: Failure with output: onlineapp.d(4): Error: incomplete mixin expression ("(){return 4;}();")
2.079.1 to 2.082.1: Failure with output: onlineapp.d(4): Error: incomplete mixin expression `"(){return 4;}();"`
2.083.1 to 2.105.3: Failure with output: onlineapp.d(4): Error: incomplete mixin expression `(){return 4;}();`
Since      2.106.1: Failure with output:
-----
onlineapp.d-mixin-4(4): Error: unexpected token `;` after call expression
onlineapp.d-mixin-4(4):        while parsing string mixin expression `(){return 4;}();`
-----

So it seems it's been an error for many years, it just became clearer since 2.106.

The rules are simple - if it can be a mixin statement, it is. Otherwise it is a mixin expression (or mixin type).

On Friday, 12 September 2025 at 12:23:21 UTC, Nick Treleaven wrote:

I did a complete 'martix' of these combinations and accidentally found the way how I did it already in the past. Actually my things were changed, it's not related to the DMD/LDC version, sorry for the false suspection.

So the solution is to put the mixin(expr) into a () and then the expression it will act BOTH an expression with a return value and a statement with unused return value.

import std;

void main() {
  enum expr = `(){return 4;}()`; //expression

  (){return 4;}()       ;   //<- works
  auto x = mixin(expr)  ;   //<- works
  auto y = (mixin(expr));   //<- works
//mixin(expr)           ;   //<- fails. mixin expects statement
  (mixin(expr))         ;   //<- THIS IS THE WHEY! :D
}

note: The expressio must be a lambda, othewise the compiler will detect no side effects and refuse to use it as a statement.

(x); <- Is not a construct that comes to my mind as useful, but this was it. This forces the mixin to expect an expression and not a statement.

Thank You all to for the help!

On Friday, 12 September 2025 at 13:27:53 UTC, realhet wrote:

Thanks for sharing it! - I did not know this works. :)

On Friday, 12 September 2025 at 08:36:42 UTC, realhet wrote:

import std;

[...]

It's seeing the eof of the mix file no?