# Findfirst for Dicts with \`nothing\` keys

**URL:** https://discourse.julialang.org/t/findfirst-for-dicts-with-nothing-keys/9432
**Category:** General Usage
**Created:** [March 1, 2018, 10:10pm UTC](https://discourse.julialang.org/t/findfirst-for-dicts-with-nothing-keys/9432 "2018-03-01T22:10:23Z")
**Posts on this page:** 1
**Showing post:** 13

<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: [March 2, 2018, 2:22pm UTC](https://discourse.julialang.org/t/findfirst-for-dicts-with-nothing-keys/9432/13 "2018-03-02T14:22:20Z")

</div>

> [@ScottPJones](#):
>
> I believe the code generated for is as fast or faster on current master than using nothing as a sentinel, and is more general.

I’m not so sure. Returning non-bitstype tuples is currently pretty hit-and-miss with respect to avoiding the allocation for the tuple.

Once this [https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706](https://discourse.julialang.org/t/immutables-with-reference-fields-why-boxed/7706) is fixed (if ever) I totally agree that sentinel values are stupid-- as far as I understand, we should have several free (already invalidated) registers where we can place our bool, and the actual return value can go via sret / other register / whatever the current ABI wants.

Maybe an easier clean fix would be to special case that `Tuple{atype, btype}` with inferred `bitstype` never allocates. Of course, unless this is packed into a tuple / array / etc, or this rule would need to be applied recursively. In other words: I am asking for a special ABI for returning pairs. I would even be happy if I was forced to annotate that I want `@pair_return_ABI` or there was a magic built-in `__unpacked_pair` that lazily materializes the tuple.

---

_[View the full topic](https://discourse.julialang.org/t/findfirst-for-dicts-with-nothing-keys/9432)._