# Should Generators finally be given eltype

**URL:** <https://discourse.julialang.org/t/should-generators-finally-be-given-eltype/20507>\
**Category:** Internals & Design\
**Created:** [February 6, 2019, 2:44pm UTC](https://discourse.julialang.org/t/should-generators-finally-be-given-eltype/20507 "2019-02-06T14:44:43Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 7, 2019, 7:34am UTC](https://discourse.julialang.org/t/should-generators-finally-be-given-eltype/20507/12 "2019-02-07T07:34:16Z")

</div>

> [@cstjean](#):
>
> inference-based eltypes (as in Julia 0.4) would be much easier to work with than the 4 data-dependent cases I have to handle when I use generators/comprehensions/broadcasting

I think the correct long-run idiomatic solution would be exposing the building blocks of what `collect` does, so that users can easily write code that assumes a certain type (as @jeff.bezanson said, like a size hint, possibly deduced from the first element obtained) yet seamlessly go to a different branch if that assumption is violated. When the compiler knows a lot, if can prune these branches and emit very efficient code, but even the worst case heuristic fallbacks (widen as necessary) are not that bad.

I have used one component of this [in the example code here](https://discourse.julialang.org/t/functional-implementation-of-collect/15177), and I am working on a strategy that does something similar for “pre-allocated” buffers for output types, but that needs quite a bit of polish.

---

_[View the full topic](https://discourse.julialang.org/t/should-generators-finally-be-given-eltype/20507)._