When not capturing the return value of a string mixin expression, I get "found `End of File` when expecting `;`"

[Nick Treleaven]

On Friday, 12 September 2025 at 09:17:10 UTC, realhet wrote:
> On Friday, 12 September 2025 at 08:44:47 UTC, Stefan Koch wrote:
>> On Friday, 12 September 2025 at 08:36:42 UTC, realhet wrote:
> Hi, thanks for quick answer!
>
> 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`

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

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

> rdmd playground.d

```
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.

> 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).

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