# Immutables with reference-fields: Why boxed?

**URL:** <https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706>\
**Category:** Internals & Design\
**Created:** [December 12, 2017, 12:44pm UTC](https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706 "2017-12-12T12:44:22Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [December 14, 2017, 9:31am UTC](https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706/21 "2017-12-14T09:31:47Z")

</div>

Thanks, then.

An intermediate step could be half-carnaval, i.e. do inline storage for struct/tuple and not for arrays. That should cause no additional nullpointer-checks and solves the most pressing API issues (but still sometimes forces people to use suboptimal illogical data-layout).

Any reason that yuyichao’s patch is not merged with #ifdefs depending on llvm version? I mean, there is a lot of llvm-version dependent conditionally compiled code flying around anyway.

(and sorry if I sound exasperated; you all are doing really cool work, can’t say this enough)

---

_[View the full topic](https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706)._