[RFC] buffer.freeze

[hardlyardi]

Rendered.

[alexmccord]

I doubt these two functions are worth the remaining valuable slots.

[hardlyardi]

i think there'll always be some demand, but i'll remove that bit since those usually would not be in hotpaths (also they'd always be fastcall1). the only one that imo could be worth considering is isfrozen

[alexmccord]

How will this interact with buffer slices? Freezing a buffer slice is kind of nonsensical due to memory aliasing, which probably means buffer slices aren't buffers, they're a different primitive altogether.

[jackdotink]

I think this probably means that buffer freezing is a bad idea.

[hardlyardi]

How will this interact with buffer slices? Freezing a buffer slice is kind of nonsensical due to memory aliasing, which probably means buffer slices aren't buffers, they're a different primitive altogether.

buffer slices are not currently a feature. I am aware of the conflict, but wrote this up anyways to get the discussion about immutability and buffers out there - I think frozencopy would probably be a viable alternative.

[MagmaBurnsV]

I think buffers should act as the mutable variant of packed strings and have little utility in being readonly. If someone wants an immutable buffer, they can just use buffer.tostring.

[jackdotink]

The problem is that string APIs are an order of magnitude slower than buffer APIs. Buffers are always better, even for immutable data.

[vegorov-rbx]

Suggestion for this feature has been made before and our answer remains the same.
We do not have plans to introduce freezing for buffers because of the performance consideration for the additional checks, impact on code size and incompatibility with existing Luau C API for buffer access (which cannot enforce immutability because modifications are not going through API).