# What accepted proposal is everyone most excited about?

**URL:** <https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438>\
**Category:** Brainstorming\
**Created:** [May 10, 2026, 2:59pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438 "2026-05-10T14:59:39Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![darnellbrawner](https://ziggit.dev/letter_avatar_proxy/v4/letter/d/bcef8e/32.png) [@darnellbrawner](https://ziggit.dev/u/darnellbrawner)\
**Post date:** [May 10, 2026, 2:59pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/1 "2026-05-10T14:59:39Z")

</div>

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

> <https://github.com/ziglang/zig/issues/23173>
>
> 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 .

---

<div class="post-metadata">

**Author:** ![pierrelgol](https://ziggit.dev/user_avatar/ziggit.dev/pierrelgol/32/10233_2.png) [@pierrelgol](https://ziggit.dev/u/pierrelgol)\
**Post date:** [May 10, 2026, 3:21pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/2 "2026-05-10T15:21:11Z")

</div>

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

---

<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:** [May 10, 2026, 4:21pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/3 "2026-05-10T16:21:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ForeverZer0](https://ziggit.dev/user_avatar/ziggit.dev/foreverzer0/32/2443_2.png) [@ForeverZer0](https://ziggit.dev/u/ForeverZer0)\
**Post date:** [May 10, 2026, 4:52pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/4 "2026-05-10T16:52:25Z")

</div>

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](https://codeberg.org/ziglang/zig/issues/32032)
- [Builtin Matrix type #4960](https://github.com/ziglang/zig/issues/4960)
- SPIR-V backend

---

<div class="post-metadata">

**Author:** ![AlexandreBlais42](https://ziggit.dev/user_avatar/ziggit.dev/alexandreblais42/32/5835_2.png) [@AlexandreBlais42](https://ziggit.dev/u/AlexandreBlais42)\
**Post date:** [May 10, 2026, 5:06pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/5 "2026-05-10T17:06:03Z")

</div>

[support torrenting for fetching and serving packages · Issue #23236 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/23236)  
[Proposal: restricted function types · Issue #23367 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/23367)  
[safe recursion · Issue #1006 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/1006)  
[enhance the fuzzing algorithm to be competitive with other mainstream fuzzers · Issue #20804 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/20804)  
[remove @TypeOf and anytype; introduce |T| syntax #32099](https://codeberg.org/ziglang/zig/issues/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.

---

<div class="post-metadata">

**Author:** ![IntegratedQuantum](https://ziggit.dev/user_avatar/ziggit.dev/integratedquantum/32/782_2.png) [@IntegratedQuantum](https://ziggit.dev/u/IntegratedQuantum)\
**Post date:** [May 10, 2026, 7:39pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/6 "2026-05-10T19:39:43Z")

</div>

If had to pick only one, it would probably be [debug safety feature: runtime undefined value detection · Issue #211 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/211), 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.

---

<div class="post-metadata">

**Author:** ![jasonsmiles](https://ziggit.dev/user_avatar/ziggit.dev/jasonsmiles/32/8633_2.png) [@jasonsmiles](https://ziggit.dev/u/jasonsmiles)\
**Post date:** [May 11, 2026, 5:13am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/7 "2026-05-11T05:13:34Z")

</div>

> [@pierrelgol](#):
>
> [Fixed-point number support of some kind in the language #1974](https://github.com/ziglang/zig/issues/1974)

Ghost’s post is God Tier and Andrew’s title change gave me a chuckle

Anyway, as for an answer to the thread, I personally haven’t perused the proposals as I’m really just a beginner and so I don’t know what to want that Zig doesn’t have, but I have been enjoying reading the answers from others

---

<div class="post-metadata">

**Author:** ![g-syn](https://ziggit.dev/user_avatar/ziggit.dev/g-syn/32/9565_2.png) [@g-syn](https://ziggit.dev/u/g-syn)\
**Post date:** [September 4, 2026, 6:52pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/8 "2026-09-04T18:52:28Z")

</div>

Those are mainly motivated by my embedded work:

The [fixed-point numbers](https://github.com/ziglang/zig/issues/1974) would be helpful for making fast DSP algorithms.

I would also like to see the [new stackless coroutine IO implementations](https://github.com/ziglang/zig/issues/23446) as I believe it could be the foundation upon to build a 100% zig-base RTOS (This also might be related to [Builtin function to tell you the maximum stack size of a given function · Issue #157 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/157)).

With the linker rework that @mlugg is doing, I wonder if there’s some consideration for supporting a `.zon` based linker configuration, as mentioned in this 2019 issue: [Linker scripts must die](https://github.com/ziglang/zig/issues/3206). It feels like this might be related to those issue: [Proposal: semantics for address spaces · Issue #15232 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/15232) and [enum-backed address spaces · Issue #21870 · ziglang/zig · GitHub](https://github.com/ziglang/zig/issues/21870).

For tooling, I’m pretty excited about [the fuzzer](https://github.com/ziglang/zig/issues/20804).  
I can’t find the issue, but having out-of-the-box IO fuzzing would be **game changing** for making program reliable.

---

<div class="post-metadata">

**Author:** ![Plebosaur](https://ziggit.dev/user_avatar/ziggit.dev/plebosaur/32/6857_2.png) [@Plebosaur](https://ziggit.dev/u/Plebosaur)\
**Post date:** [September 4, 2026, 7:39pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/9 "2026-09-04T19:39:47Z")

</div>

Probably this one [Extend @Vector for SPIR-V](https://codeberg.org/ziglang/zig/issues/35376)

Or really any work done around SPIR-V.

Restricted function pointers, too, if it can remove the performance penalty of V-table interfaces then that will be a massive improvement to me using the language.

An honorable mention for a proposal that’s already implemented is the removal of using namespace.

---

<div class="post-metadata">

**Author:** ![jproc](https://ziggit.dev/letter_avatar_proxy/v4/letter/j/f08c70/32.png) [@jproc](https://ziggit.dev/u/jproc)\
**Post date:** [September 5, 2026, 3:55am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/10 "2026-09-05T03:55:54Z")

</div>

anytype replacement |T| !

---

<div class="post-metadata">

**Author:** ![CMDRZero](https://ziggit.dev/user_avatar/ziggit.dev/cmdrzero/32/10421_2.png) [@CMDRZero](https://ziggit.dev/u/CMDRZero)\
**Post date:** [October 25, 2026, 5:32am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/11 "2026-10-25T05:32:24Z")

</div>

It wasn’t the top of the list, but [PR #30160](https://codeberg.org/ziglang/zig/pulls/30160) landed yesterday on master which closes [#114](https://github.com/ziglang/zig/issues/114), so progress is being made!

---

<div class="post-metadata">

**Author:** ![hemisputnik](https://ziggit.dev/user_avatar/ziggit.dev/hemisputnik/32/9625_2.png) [@hemisputnik](https://ziggit.dev/u/hemisputnik)\
**Post date:** [October 25, 2026, 8:02am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/12 "2026-10-25T08:02:41Z")

</div>

[https://codeberg.org/ziglang/zig/issues/37373](https://codeberg.org/ziglang/zig/issues/37373) for sure, this has been annoying me so much the last couple of months, that I might as well just implement it myself

---

<div class="post-metadata">

**Author:** ![xydone](https://ziggit.dev/letter_avatar_proxy/v4/letter/x/96bed5/32.png) [@xydone](https://ziggit.dev/u/xydone)\
**Post date:** [October 25, 2026, 10:00am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/13 "2026-10-25T10:00:40Z")

</div>

I haven’t even thought about this being a possibility but I want it so much now

---

<div class="post-metadata">

**Author:** ![ForeverZer0](https://ziggit.dev/user_avatar/ziggit.dev/foreverzer0/32/2443_2.png) [@ForeverZer0](https://ziggit.dev/u/ForeverZer0)\
**Post date:** [October 25, 2026, 5:00pm UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/14 "2026-10-25T17:00:43Z")

</div>

I didn’t even know they were planning a change for this, but now that I do, I concur this is worth being excited about. I don’t have any major complaints for the language itself, so these QoL features are what I appreciate the most.

I am also happy to see the file-level documentation go, and be able to just use existing syntax. For whatever reason, my editor never seemed to be able to understand multi-line file documentation, and always suggested that the first letter of each continuation line be capitalized. It wasn’t even worth the time investigating how to fix, so was just something I lived with.

---

<div class="post-metadata">

**Author:** ![QuaternionWake](https://ziggit.dev/user_avatar/ziggit.dev/quaternionwake/32/6355_2.png) [@QuaternionWake](https://ziggit.dev/u/QuaternionWake)\
**Post date:** [October 26, 2026, 2:27am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/15 "2026-10-26T02:27:48Z")

</div>

Ooooooh, this is really nice to see!

The way plain structs are special-cased here is one of the big inconsistencies in the language that has been bugging me since I started using it, nice to see it’s finally getting resolved :​D

I do wonder if there’s a nice way to extend the proposal to functions to enable generic types to exist on the file level too. Reading the comments on the issue it seems there is some talk about it, but I honestly really don’t like what’s been proposed so far, as it seems to only work on a function that only has one statement in it (the return statement).

From [castholm’s reply](https://codeberg.org/ziglang/zig/issues/37373#issuecomment-26448251), for reference:

```Zig
/// Doc comment for std.ArrayList (std/ArrayList.zig)
fn (T: type, alignment: ?mem.Alignment) struct;

items: Slice,
capacity: usize,

const Self = @This();

pub const empty: Self = .{
    .items = &.{},
    .capacity = 0,
};

pub const Slice = if (alignment) |a| ([]align(a.toByteUnits()) T) else []T;

```

I wonder if the most radical position here could be the correct one, and simply allow plain old functions to exist on the file level?

```Zig
/// Doc comment for the function
fn (T: type, items: []T) T;

// If we wanted a helper function we would have to put it in a struct
// ... and it would only be available below its declaration...
const helper = struct {
    fn add(...) { ... }
}

var sum: T = 0;
for (items) |item| {
    sum = helper.add(sum, item);
}

return sum;
// Presumably nothing would be allowed after the return

```

Maybe this could be made to work, but these files would probably require a lot bigger of a parser change than the current proposal, for a rather questionable gain.  
But it also feels like it _could_ work. Zig did manage to make a lot of kinda weird stuff work really well, and it’s not like functions on the file level are that weird of a concept in the wider programming world anyway (see: any scripting language). The more I think about this, the more it’s feeling like a rather natural extension of the current proposal.

---

<div class="post-metadata">

**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\
**Post date:** [October 26, 2026, 5:48am UTC](https://ziggit.dev/t/what-accepted-proposal-is-everyone-most-excited-about/15438/16 "2026-10-26T05:48:47Z")

</div>

I think to make generics also nicer and have a unifying syntax I would consider this syntax, we pondered about here [`anyerror` is a bad practice / with syntax](https://ziggit.dev/t/anyerror-is-a-bad-practice-with-syntax/13045) :

> [@\`anyerror\` is a bad practice / with syntax](https://ziggit.dev/t/anyerror-is-a-bad-practice-with-syntax/13045/12):
>
> what if we had comptime variables associated with a function definition something like:
> 
> ```zig
> with {
> const T = infer type;
> const R = MyTypeCalculatingFunction(T);
> } fn func(val:T) R {
> var res: R = undefined;
> for(std.meta.fields(R)) |f| @field(res, f.name) = .empty;
> return res;
> }
> 
> ```
> 
> `with` would basically add a syntactic way to have comptime variables associated with a function, so that you can avoid repeating expressions.

> [@\`anyerror\` is a bad practice / with syntax](https://ziggit.dev/t/anyerror-is-a-bad-practice-with-syntax/13045/27):
>
> And with the syntax from earlier
> 
> ```zig
> const isInt = with {
> T: type,
> const info = @typeInfo(T);
> } info == .int or info == .comptime_int;
> 
> //...
> 
> with {
> T: infer type,
> assert(isInt{T});
> } fn half(x: T) T {
> return x >> 1;
> }
> 
> ```

Through a mix of the syntax in that topic and this topic, it could be like this:

```zig
/// Doc comment for std.ArrayList (std/ArrayList.zig)
with {
    T: type,
    alignment: ?mem.Alignment = null,
} struct;

items: Slice,
capacity: usize,

const Self = @This();

pub const empty: Self = .{
    .items = &.{},
    .capacity = 0,
};

pub const Slice = if (alignment) |a| ([]align(a.toByteUnits()) T) else []T;

```

```zig
/// Doc comment for the function
with { T: type }
fn (items: []T) T {
    const helper = struct {
        fn add(...) { ... }
    }
    
    var sum: T = 0;
    for (items) |item| {
        sum = helper.add(sum, item);
    }
    
    return sum;
};

```

You also could get rid of `anytype` / type-parameter-capture, by just defining that with parameters can be inferred where it makes sense:

```zig
pub fn alignPointer(ptr: anytype, align_to: usize) ?@TypeOf(ptr) {
    const adjust_off = alignPointerOffset(ptr, align_to) orelse return null;
    // Avoid the use of ptrFromInt to avoid losing the pointer provenance info.
    return @alignCast(ptr + adjust_off);
}
pub fn alignForward(comptime T: type, addr: T, alignment: T) T {
    assert(isValidAlignGeneric(T, alignment));
    return alignBackward(T, addr + (alignment - 1), alignment);
}

```

```zig
with { T: type }
pub fn alignPointer(ptr: T, align_to: usize) ?T {
    const adjust_off = alignPointerOffset(ptr, align_to) orelse return null;
    // Avoid the use of ptrFromInt to avoid losing the pointer provenance info.
    return @alignCast(ptr + adjust_off);
}
with { T: type } pub fn alignForward(addr: T, alignment: T) T {
    assert(isValidAlignGeneric(T, alignment));
    return alignBackward(T, addr + (alignment - 1), alignment);
}

```

Conceptually this is similar to `let-syntax` in lisps or functional let-in syntax.  
Theoretically with this you even can remove the **comptime** keyword and just allow comptime parameters in the with / let syntax.

```zig
let {
    T: type,
    const R = MyTypeCalculatingFunction(T);
} fn func(val:T) R {
    var res: R = undefined;
    for(std.meta.fieldNames(R)) |name| @field(res, name) = .empty;
    return res;
}

```

Using let would also sort of match the current behavior of comptime, because comptime is more functional than runtime is, allowing you to write in a functional style (for example using function bodies for higher order programming) just generating garbage collected values and freeze the resulting immutable values to be embedded into the program as values.

> [@\`anyerror\` is a bad practice / with syntax](https://ziggit.dev/t/anyerror-is-a-bad-practice-with-syntax/13045/23):
>
> with this syntax you get some things you don’t get without it:
> 
> - inferred vs not uses syntax that is similar so it is easy to switch between needing to pass types explicitly or not and switching between those doesn’t change the signature of the inner function that is called, which makes it easy to move those functions between places where the type is inferred or explicit
> - lsp info and type checking have their own syntactic zone making it easier for people to see what is required by a type (provided they actually place their type checks/construction of dependent types in the `with`)
> - generics don’t require more levels of indentation (this is a small benefit but I think it might be good)
> - you don’t need a bunch of wrappers and helpers / or repeat a lot of things  
> you can directly write `V.vfunc(myval)` because T is inferred
> - editors could show you the `with` as context information making those variables more visible and also display what type was inferred
> - if all `with` parameters can be inferred you don’t have to specify them, so it becomes an alternative to `anytype` that also comes with zig code that describes what is allowed for the type (which seems to be the biggest complaint about anytype)
> 
> One problem in current Zig is that you can’t use a file struct when it is supposed to be a generic. With `with` we could have a syntactic rule that it can appear as the first non-comment in a file, which would mean that the with applies to the file-struct, thus we could define and use file-structs that are generics.

I am not completely sure about these ideas, but wanted to mention them, food for thought, maybe somebody can take them further or get some idea from this brainstorming we had a while ago.

I think there is potential here for a simplified / more general syntax that also has benefits.