Fixed-size array allocation and fixed-size types about rune HOT 5 CLOSED

The way you are supposed to do it is to have an empty array and resize it:

p = arrayof(u32).resize(4096)

And from what I can tell there's nothing terribly inefficient about it (#35 (comment))

define internal void @array() !dbg !240 {
  %.tmp1 = alloca %struct.runtime_array
  store %struct.runtime_array zeroinitializer, %struct.runtime_array* %.tmp1
  ; statement 0x3dd assignment p = arrayof(u32).resize(4096u64)
  call void @runtime_freeArray(%struct.runtime_array* %.tmp1)
  call void @runtime_resizeArray(%struct.runtime_array* %.tmp1, i64 4096, i64 4, i1 zeroext 0), !dbg !241
  call void @runtime_moveArray(%struct.runtime_array* @array_p, %struct.runtime_array* %.tmp1), !dbg !241
  ; statement 0x3e5 return
  ret void, !dbg !241
}

Which in the end quickly comes down to calling runtime_allocArray

from rune.

Ah okay, so it is more like Python/Javascript than a systems language in this regard if I understand it?
There is no notion of "fixed-size type", there is just an Array type which has a length property

from rune.

The language is not complete yet, so some optimisations may be missed. It is supposed to be systems programming language.

From what I can see there's no fixed-size array, but why do you need it?
It's not more efficient than one allocation of an array of the needed size

from rune.

For two reasons:

1. You lose the type-soundness of being able to specify "this a function that a buffer/array of a specific size"

Now instead of it being a type-level constraint, you must move this sort of information and validation into userland. This means you have a have few choices as a user:

• A) Repeatedly validate some type like [u32] to make sure it's the right length as you pass it across your functions that expect something like [u32; 256]
• B) Create a wrapper-class that does validation of the length in it's constructor (IE, "parses") the array. Use the wrapper class instead. But this is not suitable for high-performance code if the wrapper class isn't inlined/transparent in terms of machine code and zero-cost.
• C) Create a "proof-type" and token, which you must pass to all methods that accept the e.g. [u32], guaranteeing that it has been validated to be the right length for the method. See: https://www.foonathan.net/2022/11/proof-types

2. From the language/compiler perspective, there is less information in the type preserved than the user had initially provided it with. In other words, we suffer from a "lossy encoding" of information.

from rune.

I thought about it and I think that if you need to specify a certain number of elements of the same type there's two cases:

• number of elements is large, when this happens then I don't see a reason to why not write the code in the style that supports arbitrarily sizem the exact size should not matter
• number of elements is small, then you probably assigm specific funcitons to each element of the array, so it makes more sence to name them and put them into a structure

This deals with the unnecessary checks problems

Now we can see more clearly that through "lossy encoding" compiler misses out on some optimisations for large number of elements, although the gains are probably rather not significant

I couldn't come up with an example where you really need to have a certain number of elements, maybe you have one?

from rune.