# Inference bug when using nested generators?

**URL:** <https://discourse.julialang.org/t/inference-bug-when-using-nested-generators/82991>\
**Category:** General Usage\
**Created:** [June 19, 2022, 12:51am UTC](https://discourse.julialang.org/t/inference-bug-when-using-nested-generators/82991 "2022-06-19T00:51:28Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [June 19, 2022, 10:30am UTC](https://discourse.julialang.org/t/inference-bug-when-using-nested-generators/82991/5 "2022-06-19T10:30:12Z")

</div>

`sum(x^2 for x in f(5))` is inferable while `sum(x for x in f(5))` isn’t. Both use the most generic `sum(a; kw...) = sum(identity, a; kw...)` in reduce.jl, and I followed the trail through `mapreduce`, `mapfoldl`, `mapfoldl_impl`, and a recursive `_xfadjoint`. The type instability seems to be rooted in `MappingRF`’s 2nd type parameter not being inferred in `_xfadjoint` for the `x^2` case.

I think it runs `Base._xfadjoint(Base.BottomRF(Base.add_sum), Base.Generator(identity, (x^2 for x in f(5)) ) )`. The `x^2` case returns a `MappingRF` instance that contains another `MappingRF` instance, while the `x` case returns an unnested `MappingRF` instance. `Test.@inferred` is able to tell that the `x^2` case is not inferable, but `@code_warntype` prints blue text for the call’s return type, a weird discrepancy I’ve noticed before [in much stranger circumstances](https://discourse.julialang.org/t/why-is-this-expression-type-unstable/80648/2).

---

_[View the full topic](https://discourse.julialang.org/t/inference-bug-when-using-nested-generators/82991)._