# Result type spreading

**URL:** <https://ziggit.dev/t/result-type-spreading/13260>\
**Category:** Brainstorming\
**Tags:** language\
**Created:** [November 28, 2025, 3:03pm UTC](https://ziggit.dev/t/result-type-spreading/13260 "2025-11-28T15:03:00Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hachanuy](https://ziggit.dev/user_avatar/ziggit.dev/hachanuy/32/3619_2.png) [@hachanuy](https://ziggit.dev/u/hachanuy)\
**Post date:** [November 28, 2025, 3:03pm UTC](https://ziggit.dev/t/result-type-spreading/13260/1 "2025-11-28T15:03:00Z")

</div>

I think people can agree that writing

```zig
const result: u16 = @as(u16, @intFromFloat(float1)) + 
                    @as(u16, @intFromFloat(float2));

```

is painful. I am thinking that Zig can have a result type spreading mechanism. Right now, if an expression is assigned to a variable, it gets the type based on [RLS](https://ziglang.org/documentation/master/#Result-Location-Semantics), which is essentially

```zig
const result: u16 = @as(u16, @intFromFloat(float1));

```

We can imagine that

```rs
const result: u16 = @intFromFloat(float1) + @intFromFloat(float2);

```

is the same as

```rs
const result: u16 = @as(u16, @intFromFloat(float1) + @intFromFloat(float2));

```

This obviously doesn’t work, but what if Zig automatically spreads the `@as` calls when it sees `+`, `-`, `*` or `/` binary operators, so the above code becomes

```zig
const result: u16 = @as(u16, @intFromFloat(float1)) + 
                    @as(u16, @intFromFloat(float2));

```

---

<div class="post-metadata">

**Author:** ![npc1054657282](https://ziggit.dev/user_avatar/ziggit.dev/npc1054657282/32/5790_2.png) [@npc1054657282](https://ziggit.dev/u/npc1054657282)\
**Post date:** [November 28, 2025, 4:31pm UTC](https://ziggit.dev/t/result-type-spreading/13260/2 "2025-11-28T16:31:31Z")

</div>

I think this makes sense.  
Especially considering that there are already similar proposals to propagate result types to more operators:  
[Proposal: restrict `++` to allow it to interact with RLS · Issue #24908 · ziglang/zig](https://github.com/ziglang/zig/issues/24908)

However, similar proposals have already been rejected in terms of arithmetic symbols.

[RLS for bitwise not operator `~` · Issue #25497 · ziglang/zig](https://github.com/ziglang/zig/issues/25497)

The reason for the rejection is equally convincing: This change is breaking, and under the same expression, the semantics commonly used in the past and the semantics accepted for this modification will be completely opposite. Especially when the vast majority of languages adopt forward type derivation rather than backward derivation of result types.

However, I believe the more fundamental reason why previous related similar proposals were rejected lies in the lack of sufficient consistency. I absolutely cannot accept the adoption of result type derivations for only a few of these symbols, but if all mathematical symbols were to adopt result type derivations, I would readily accept it.

But the problem with breaking remains huge.

---

<div class="post-metadata">

**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\
**Post date:** [November 29, 2025, 1:07am UTC](https://ziggit.dev/t/result-type-spreading/13260/3 "2025-11-29T01:07:45Z")

</div>

its worth mentioning [allow integer types to be any range · Issue #3806 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/3806)

The semantics of them is that operations will result in a type with an increased/reduced range, depending on the operation. This removes trivial casting. The benefit of that is you can just write equations without caring for the size until the end.

Ofc wrapping and saturating operators will still exist, with the addition of asserting operators, which keep the current behaviour.