# The expression solution

**URL:** <https://discourse.julialang.org/t/the-expression-solution/103435>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [September 1, 2023, 7:52am UTC](https://discourse.julialang.org/t/the-expression-solution/103435 "2023-09-01T07:52:40Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [September 1, 2023, 12:44pm UTC](https://discourse.julialang.org/t/the-expression-solution/103435/14 "2023-09-01T12:44:04Z")

</div>

Compiler & type system development is hard, and there have been more pressing concerns (like compilation speed, compilation caching, …) since 1.0.

It’s also good to remember that retrofitting sum types into the existing language (e.g. by forcing users to take care of the return type of `findfirst` before their code compiles) is (in general) a breaking change - and [Julia just isn’t at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). Arguably, code that uses `findfirst` and ignores the `nothing` case _may_ be broken - but it may also not be, if in the semantics & context surrounding the call the developer knows that this will never be `nothing`. That’s not something we can know though, so changing it and forcing users to handle that case explicitly (barring a perfectly knowledgeable compiler, which we don’t have) is not something that can be done right now (unfortunate as that is), because that would change currently working (& correct!) code into code that is now broken.

That’s not to say we’ll never get sum types (or something like it) - just that the path to getting there needs to take A LOT of existing code into account, which adds to the complexity/difficulty.

---

_[View the full topic](https://discourse.julialang.org/t/the-expression-solution/103435)._