RFC: Struct-buffer sugar

[YarikSuperpro]

(Rendered)
Adds compiler-only struct syntax as sugar over buffer serialization.

This proposal introduces no runtime or VM changes and compiles entirely to existing buffer operations.

[PhoenixWhitefire]

Hello, you're supposed to add a link to the markdown preview in your fork to make it easier to read, for example:

Rendered.

([Rendered](https://github.com/YarikSuperpro/rfcs/blob/buffer-sugar/docs/syntax-struct-buffer-sugar.md))

---

A problem right now is that the bytecode compiler does not actually run Luau's type inference (for performance reasons, I've heard, but the type system also has its own bugs that Native Codegen already has to manage fallbacks for). It does not know what the type of a value is, frequently unless that value is a local that is never re-assigned or a constant;

local x = 10
x = 5
return _G[x] --> `GETTABLE` and not `GETTABLEN`

https://play.luau.org/#N4IgbiBcBMA0IGMogDYHsEEMUAIAeOAvDgIwAMAOgHYHECs1ATgKYAuAro1TgPoDiAbTwBdaiHgBnKKDQAHVgEsAtgoBemRWioAZZmGYoocEABNmAI3YBzXfsMwAvvHNRWjdswdA

This seemed like it may be a barrier for this feature, which is why I'm pointing it out.

[metatablecat]

I don't really see the point in reserving struct like this to generate structs when its already easy to just allocate the buffer yourself and push the values in, also not to mention that almost nobody does this in the Luau world.

Structs are also not that useful without pointers, which Luau will never get because completely different semantics to a low level language like C.

Dont get me wrong, tables are slower than this approach but again, its probably a few microseconds between reading bytes out of a buffer vs indexing a table, and this kind of performance is only really needed if you're writing code where performance is of the upmost important, which in 99% of places, isn't.

[YarikSuperpro]

I don't really see the point in reserving struct like this to generate structs when its already easy to just allocate the buffer yourself and push the values in, also not to mention that almost nobody does this in the Luau world.

"You can already do it manually" is not an argument against syntax sugar. It is an argument against most language features.
"Almost nobody does this" is not a technical objection either; it just describes current friction.
Structs do not need pointers to be useful. Packed layouts are valuable for serialization, networking, deterministic storage, and reducing table overhead.
And dismissing small costs because they are small in isolation is how inefficiency becomes the default at scale.
The point of this RFC is not to make buffers possible. They already are. The point is to make the efficient path clearer, safer, and less obnoxious to write.
Structs also do not become useless just because Luau has no native pointers. Even if native pointer semantics never exist, pointer-like indirection is still possible through handles or indexed reference pools. For example, a struct can store a U8/U16 slot in a buffer, and that slot can reference a value inside a proxy array or object pool. That is not the same as raw C pointers, but it is still enough to model references, relationships, and compact indirection when needed.