# New iterate interface and type stability

**URL:** <https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222>\
**Category:** General Usage\
**Created:** [May 29, 2018, 8:12am UTC](https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222 "2018-05-29T08:12:11Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![krcools](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/krcools/32/10212_2.png) [@krcools](https://discourse.julialang.org/u/krcools)\
**Post date:** [May 29, 2018, 8:12am UTC](https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222/1 "2018-05-29T08:12:11Z")

</div>

I have a general question about the new iterate interface: it seems that it is inherently type unstable. What I understand from various posts on this topic is that the introduction of the new interface is accompanied with a new and improved optimiser that can build in all practical situations code that does not suffer from this semantics level type instability.

I do wonder however whether this changes the contract with the user of Julia. Before 0.7 the rule was: write type stable code and you will get near c performance. Is this rule of thumb now changing to something more complicated? Something like: Write code that our optimiser - which is a very complicated algorithm sitting inside an opaque box - can deal with, and you get near c performance? Or are there well defined mild cases of type instability that are allowed, and now even encouraged?

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [May 29, 2018, 8:30am UTC](https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222/2 "2018-05-29T08:30:46Z")

</div>

It boils down to Julia now effectively handling small type unions, which (if I recall correctly) had to be extended to nested unions to make the new iterator work. Maybe there is a doc entry for this in the latest docs? Otherwise there probably should be.

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [May 29, 2018, 8:42am UTC](https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222/3 "2018-05-29T08:42:55Z")

</div>

> [@krcools](#):
>
> I do wonder however whether this changes the contract with the user of Julia. Before 0.7 the rule was: write type stable code and you will get near c performance. Is this rule of thumb now changing to something more complicated? Something like: Write code that our optimiser - which is a very complicated algorithm sitting inside an opaque box - can deal with, and you get near c performance?

I would instead say that it has changed from “write type stable code and you will get near c performance” to “write type stable code and you will get near c performance, but if you return small unions that is usually fine too”

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [May 29, 2018, 11:01am UTC](https://discourse.julialang.org/t/new-iterate-interface-and-type-stability/11222/4 "2018-05-29T11:01:14Z")

</div>

Is there some documentation on this somewhere. As long as it is deterministic and documented one can rely on this as a user.