# Candid code generation for nullable types

**URL:** <https://forum.dfinity.org/t/candid-code-generation-for-nullable-types/6820>\
**Category:** Developers\
**Created:** [August 30, 2021, 7:46pm UTC](https://forum.dfinity.org/t/candid-code-generation-for-nullable-types/6820 "2021-08-30T19:46:06Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![rossberg](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rossberg/32/795_2.png) [@rossberg](https://forum.dfinity.org/u/rossberg)\
**Post date:** [August 31, 2021, 6:59am UTC](https://forum.dfinity.org/t/candid-code-generation-for-nullable-types/6820/4 "2021-08-31T06:59:30Z")

</div>

Well, my explanation applies to Candid as well: in Candid, `null ≠ opt null`. The JS binding needs to define a mapping that can faithfully represent this distinction. And it can only define this mapping uniformly, without knowing any context.

Throwing in `undefined` as a secondary nullish value, like JS did, does not solve the basic problem anyway. It still does not compose and just kicks the can down the road. For example, someone might happen to need type `?(?(?T))` somewhere.

(FWIW, these observations apply to union types in general: unions are fundamentally non-compositional and thus a poor basis for composing data structures. This is in contrast to variants, of which options are a special case.)

---

_[View the full topic](https://forum.dfinity.org/t/candid-code-generation-for-nullable-types/6820)._