# Missing data and NamedTuple compatibility

**URL:** <https://discourse.julialang.org/t/missing-data-and-namedtuple-compatibility/8136>\
**Category:** Internals & Design\
**Created:** [January 3, 2018, 5:52pm UTC](https://discourse.julialang.org/t/missing-data-and-namedtuple-compatibility/8136 "2018-01-03T17:52:39Z")\
**Posts on this page:** 1\
**Showing post:** 34

<div class="post-metadata">

**Author:** ![jeff.bezanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff.bezanson/32/48_2.png) [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)\
**Post date:** [March 17, 2018, 6:02pm UTC](https://discourse.julialang.org/t/missing-data-and-namedtuple-compatibility/8136/34 "2018-03-17T18:02:18Z")

</div>

Well, I’m a bit disappointed that IndexedTables.jl calls promote\_op. It didn’t when I started working on it. But there’s a hierarchy of inference-dependence:

1. Best: don’t ever call promote\_op or return\_type.
2. Mostly OK: call return\_type, but only use it as a performance hint, making sure to give the same result no matter what it returns.
3. Bad: program result depends on return\_type.

As for promote\_typejoin, we’ll have to take it up with Jameson. If I recall, his concern is about the overhead of copying part of the result every time the element type changes. But I doubt we have sufficient data on this. We could also try style (2) above, using return\_type to “guess” an element type.

As for the non-composability of needing promote\_typejoin methods for new containers, I agree with David only to a certain point. First, how many row types do we really need? You can represent any kind of array or table data with just tuples, so that type is a rather low-level aspect of the implementation. It doesn’t seem so crazy that a new kind of row would need one extra method to fine-tune its type behavior (_certainly_, I hope, not affecting correctness!). Second, don’t we need these kinds of definitions anyway? Wouldn’t you similarly want to promote `MyRow{DataValue{T}}` and `MyRow{DataValue{S}}`?

> [@davidanthoff](#):
>
> would now probably compile specialized methods for 2^n different type signatures

Don’t worry about that — we already compile way too many specializations and it’s on us to do better. And at risk of stating the obvious, all 2^n won’t actually occur; if you have 50 columns we will not literally need 2^50 methods…

---

_[View the full topic](https://discourse.julialang.org/t/missing-data-and-namedtuple-compatibility/8136)._