why is this cast required?

Dejan Lekic dejan.lekic at gmail.com
Sat Sep 26 10:36:45 UTC 2026


On Friday, 25 September 2026 at 15:52:04 UTC, DanielG wrote:
> I see, thank you!
>
> Do you (or anyone else) know the reason for that limitation? Is 
> there some obvious situation where the ambiguity is preferable, 
> versus simply inferring - or trying to infer - the expected 
> type?
>
> ie, superficially it seems like the compiler could say, "Hey, 
> they are trying to use this array in the context of a [type X] 
> argument - let's assume that for the moment, and see if it 
> works."
>
> Put another way, why is a function argument treated differently 
> than the right side of an explicitly-typed variable assignment?

You could answer your own question yourself by thinking why the

```d
exec([
     delegate () => 1,
     () => two(),
]);
```

workaround works? Think, what is the difference between `() => 1` 
and `delegate () => 1` ? - The `() => 1` lambda does not access 
any variables or functions in the outer scope. As it is 
completely self-contained D will optimise it and make it into a 
raw function pointer (`int function()`). So, you end up with this 
kind of array literal: `[ int function(), int delegate() ]` . An 
array like this will be rejected by compiler, so I "fixed" it in 
my previous post by explicitly making the first element a 
delegate, and that works.


More information about the Digitalmars-d-learn mailing list