# Type inference broken?

**URL:** https://discourse.julialang.org/t/type-inference-broken/5373
**Category:** Internals & Design
**Created:** [August 14, 2017, 9:43am UTC](https://discourse.julialang.org/t/type-inference-broken/5373 "2017-08-14T09:43:10Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![PabloZubieta](https://avatars.discourse-cdn.com/v4/letter/p/ee7513/32.png) [@PabloZubieta](https://discourse.julialang.org/u/PabloZubieta)
#### Post date: [August 14, 2017, 7:26pm UTC](https://discourse.julialang.org/t/type-inference-broken/5373/7 "2017-08-14T19:26:55Z")

</div>

> Imagine I want to use the return type of a function to define an output array of that type.

The following describes how this is handled generally in Base to have inference-independent behavior (except for empty arrays), avoiding what @mauro3 pointed above. Granted, it won’t be generally inferable but it will give you a tight element-typed-array when not inferable.

> [@Alternatives to \`Base.promote\_op(op, ::Type...)\` for \`op::Type\`?](https://discourse.julialang.org/t/alternatives-to-base-promote-op-op-type-for-op-type/5289/8):
>
> The behavior of promote\_op was initially intended for some operations between arrays and scalars and for broadcast, but we’ve gradually moved from relying on it. The general strategy in Base when we want to rely on inference for predicting, for example, the element type of an array is the following: Use Core.Inference.return\_type or related functions to get an idea of the return type R. If R is concrete, go ahead, use that. If that is not the case and your array is empty, then also use R. Othe…

---

_[View the full topic](https://discourse.julialang.org/t/type-inference-broken/5373)._