What accepted proposal is everyone most excited about?

darnellbrawner · May 10, 2026, 2:59pm

One wish thread was fun but theres a lot of stuff in the pipeline especially if u browse the GitHub pile.

introduce new float types; remove `@setFloatMode`

opened 12:28AM - 10 Mar 25 UTC

proposal accepted

Rather than a setting, there will be new float types: * `real16` * `real32` *… `real64` * `real128` These types guarantee `@sizeOf` but otherwise have **non-well-defined memory layout**. `@bitCast` is not allowed on this type, and they are not allowed in `extern` or `packed` structs. This is a conservative choice that may or may not be relaxed in a future proposal. These types are different than their `f16`, `f32`, `f64`, and `f128` counterparts in that: * They cannot store NaN, -inf, or +inf. * No operations can produce +inf or -inf. If they would, checked illegal behavior occurs instead. * No operations can produce NaN. If they would, checked illegal behavior occurs instead. * Saturating arithmetic can be used to avoid potential illegal behavior. * Cannot distinguish between positive or negative zero. * Arithmetic operations do not follow IEEE float semantics. They may: * Produce different results on different targets * Produce different results in different optimization modes * Use the reciprocal of an argument rather than perform division. * Perform floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-add). * Perform algebraically equivalent transformations that may change results in floating point (e.g. reassociate) * Any operation may use any rounding mode. Reals implicitly coerce into floats, however, `@realFromFloat` is required to convert a float to real, which invokes checked illegal behavior if the value is NaN, -inf, or inf. `@setFloatMode` is to be eliminated. Users would be encouraged to choose real types unless deterministic IEEE floating point semantics are required. Therefore, the floating point types would be renamed to `float16`, `float32`, `float64`, and `float128`.

Look interesting to me making use of r32 , r64 when you don’t need deterministic behavior but speed .

pierrelgol · May 10, 2026, 3:21pm

in no specific order :
Proposal: add .len field to vector values #17886
add builtins: @rotl and @rotr #7183
Fixed-point number support of some kind in the language #1974
Builtin Matrix type #4960
Proposal: add @memCast for a class of safe pointer casts #23935
allow ranges when switching on enums #15556
Proposal: restricted function types #23367
add vec2, vec3, vec4 types to the language #32032

npc1054657282 · May 10, 2026, 4:21pm

Proposal: restricted function types · Issue #23367 · ziglang/zig
Proposal: Change extern modifier for structs to mean “guaranteed layout”, not “for use with C”. · Issue #6700 · ziglang/zig
Proposal: testing @compileError · Issue #513 · ziglang/zig
add @backingInt and @fromBackingInt for converting between packed structs, packed unions, enums and their integer representations · Issue #18882 · ziglang/zig
#32029 - rename @field to @member for clarity - ziglang/zig - Codeberg.org
exempt known-finite operations (for loops) from eval branch quota · Issue #16983 · ziglang/zig
require parentheses sometimes to disambiguate confusing operator precedence · Issue #114 · ziglang/zig

ForeverZer0 · May 10, 2026, 4:52pm

As a hobbyist whose development is often centered around game development, most of my “wish-list” for the language is likewise related to better support and ergonomics for that.

add vec2, vec3, vec4 types to the language #32032
Builtin Matrix type #4960
SPIR-V backend

AlexandreBlais42 · May 10, 2026, 5:06pm

support torrenting for fetching and serving packages · Issue #23236 · ziglang/zig · GitHub
Proposal: restricted function types · Issue #23367 · ziglang/zig · GitHub
safe recursion · Issue #1006 · ziglang/zig · GitHub
enhance the fuzzing algorithm to be competitive with other mainstream fuzzers · Issue #20804 · ziglang/zig · GitHub
remove @TypeOf and anytype; introduce |T| syntax #32099

Edit: I couldn’t find the proposal for it, but compiler state serialization is also something I’m excited about. It would enable incremental rebuilds without the need for --watch by caching the entire state of the compiler after a build.

IntegratedQuantum · May 10, 2026, 7:39pm

If had to pick only one, it would probably be debug safety feature: runtime undefined value detection · Issue #211 · ziglang/zig · GitHub, kind of an odd one, but I think this would make debugging a lot easier in the scenarios where it does apply. It is always quite confusing to debug undefined value errors, since they often result in odd behavior instead of straight up crashing.