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