# Recommended idiom for collecting narrowest type

**URL:** <https://discourse.julialang.org/t/recommended-idiom-for-collecting-narrowest-type/136604>\
**Category:** General Usage\
**Tags:** question, collection, collections\
**Created:** [April 7, 2026, 12:14pm UTC](https://discourse.julialang.org/t/recommended-idiom-for-collecting-narrowest-type/136604 "2026-04-07T12:14:12Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [April 9, 2026, 8:18am UTC](https://discourse.julialang.org/t/recommended-idiom-for-collecting-narrowest-type/136604/13 "2026-04-09T08:18:44Z")

</div>

> [@Tamas\_Papp](#):
>
> Suppose I have a `Vector` with an abstract element type. What is the recommended idiom for collecting the elements into a vector with the narrowest possible element type?

How to collect an iterator, `X`, into an instance of `Array`, `Y`, such that `eltype(Y)` is based on the `typejoin` of the type of each value of `X`:

- Using Collects.jl, which improves upon the interface and implementation of `collect`:

- Using `collect`, if you want to avoid depending on Collects.jl for some reason:

> [@Tamas\_Papp](#):
>
> Is it _documented_ which construct actually tries to find the narrowest type? Empirically it works, but what does the language guarantee?

The documentation says:

> The element type of the returned array is based on the types of the values collected. However, if the iterator is empty then the element type of the returned (empty) array is determined by type inference.

So the docs do not specify whether types are combined with `typejoin` or with promotion.

In my opinion:

- It would be breaking for `Base` to change this behavior of `collect` regarding returned eltype.

- However, a package adding a method to `collect` could do this. IMO that would be a bad practice, but allowed according to the contract as specified in the docs.

In any case, there is Collects.jl, which:

- Generalizes the `collect` interface.

- Documents the behavior in detail.

In summary: just use Collects.jl if you are worried about `collect` for any reason. Its topic here on Discourse:

- [New package: Collects.jl - meant to improve upon and generalize the interface of collect](https://discourse.julialang.org/t/new-package-collects-jl-meant-to-improve-upon-and-generalize-the-interface-of-collect/129468)

> [@jules](#):
>
> Julia has some heuristics which Union types it will choose in such scenarios and when it falls back to `Any`.

That is just ~~`typejoin`~~ `promote_typejoin`.

> [@adienes](#):
>
> also comprehensions promote weirdly. `[1, 2.0]` becomes a `Float64[]` when you may have wanted `Real`.

While the syntax is similar, there are multiple distinct things colloquially referred to as “comprehension”. The form you refer to (`[1, 2.0]`) does promotion, while the topic here, as defined in the OP, is the form that does `typejoin`.

> [@Deduction42](#):
>
> Is there a way to specify promote behaviour when using a comprehension, or a map, or a collect?

> [@mbauman](#):
>
> better API/name/idiom for incremental widening, somewhat akin to [BangBang.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/BangBang). There’s private functionality in base that allows you to specify the allocator that `collect` uses, and it’d be very cool for this to also allow you to explicitly specify how it chooses the next wider value (e.g., `promote`, `typejoin`, unions, or some mix thereof).

@Deduction42 @mbauman creating an issue on the Collects.jl repo:

- [allow using promotion instead of `typejoin` · Issue #73 · JuliaCollections/Collects.jl · GitHub](https://github.com/JuliaCollections/Collects.jl/issues/73)

Feel free to provide more specific suggestions.

---

_[View the full topic](https://discourse.julialang.org/t/recommended-idiom-for-collecting-narrowest-type/136604)._