[konstantinua00]

one thing I never understood about VLAs - discussion about them always hits a "can't put it on stack safely" and gets halted, forever

why not to make it heap-only type? it seems such a useful addition to type system, why ignore it due to one usecase?

[Out_of_Characte]

Because arrays simply do not deal with fragmentation. Yes, you could probaly get decent performance on a modern system that has memory overcommit strategy where you could allocate sparse adress ranges where you would probaly never run out of pointers unless you actually write to your variable array.

But its just kind of mediocre and you're better off actually dealing with the stack if you can actually deal with certain fixed sizes.

[konstantinua00]

...what are you talking about?

array-like storage with dynamic size has existed since forever - it's vector. over or undercommitting is a solved problem

VLA is the way to bring that into type system, so that it can be it's own variable or struct member, with compiler auto-magic-ing size reading to access members after it

[Out_of_Characte]

> auto-magic-ing size reading to access members after it

From the article

>we now have everything we need to calculate the size, offset and alignment of every field, regardless of their positioning in the struct. >init to allocate the memory >get to get a pointer to a field >resize to resize the arrays >deinit to free the memory

You're now suggesting to do exactly what the article is about without being aware of it.

[ori_b]

Those effectively exist. They're called slices.

[uecker]

You can also put them safely on the stack. The VLA is discussion is just irrational.