compile time arrays not built in dependency order

[pd-giz-dave]

Describe the bug

Compile time arrays are built by _vinit in wrong order resulting in initialisation failure

Reproduction Steps

Compile and run this code:

const array1 = [1]
const array2 = [array1]
const array3 = array2[0]
fn main() {
	assert array3 == array1
}

Expected Behavior

I expect it to run

Current Behavior

_vinit builds the arrays in this order: array1, array3, array2
but array3 is dependent on array2 which causes an out of bounds error

Possible Solution

None found

Additional Information/Context

No response

V version

V 0.4.11 52ae3f

Environment details (OS name and version, etc.)

v doctor
|V full version      |V 0.4.11 52ae3f2476b70e5590846b176fb176fe1475d13b
|:-------------------|:-------------------
|OS                  |linux, "EndeavourOS Linux"
|Processor           |16 cpus, 64bit, little endian, AMD Ryzen 7 5800H with Radeon Graphics
|Memory              |1.19GB/30.74GB
|                    |
|V executable        |/home/dave/v/v
|V last modified time|2025-07-05 14:19:25
|                    |
|V home dir          |OK, value: /home/dave/v
|VMODULES            |OK, value: /home/dave/.vmodules
|VTMP                |OK, value: /tmp/v_1000
|Current working dir |OK, value: /home/dave/precious/fellsafe/v
|                    |
|Git version         |git version 2.50.0
|V git status        |weekly.2025.16-398-g52ae3f24
|.git/config present |true
|                    |
|cc version          |cc (GCC) 15.1.1 20250425
|gcc version         |gcc (GCC) 15.1.1 20250425
|clang version       |clang version 20.1.7
|tcc version         |tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
|tcc git status      |thirdparty-linux-amd64 696c1d84
|emcc version        |N/A
|glibc version       |ldd (GNU libc) 2.41

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-23283

[jorgeluismireles]

The error for your code is:

  message: array.get: index out of range (i,a.len):0, 0

I think the initial problem is to permit to compile an array3 even with large sizes (how to know how big is array2 though is not mutable?) and it works when array3 is not used:

const array1 = [1]
const array2 = [array1]
const array3 = array2[1000][1000] // <- does not complain at all
fn main() {
	dump(array1)
	dump(array2)
}

[code.v:5] array1: [1]
[code.v:6] array2: [[1]]

[pd-giz-dave]

My real code that highlighted this issue is more complex, the array3 is actually built by a compile time function that takes parameters: const combined_thresholds = [-40, -34, -28, -22, -16, -10, -4, -1] // most black to least black // [0] [1] [2] [3] [4] [5] [6] [7] pub const blobs_edge_limits = build_limits(0, 3, 5) pub const finder_edge_limits = build_limits(2, 4, 6) pub const extractor_edge_limits = build_limits(3, 7) // build_limits - compile time function to construct the limits from a list of indices fn build_limits(thresholds ...int) []u8 { mut limits := []u8{len: thresholds.len} for limit, threshold in thresholds { limits[limit] = mono_buckets[combined_thresholds.len - 1][threshold] } return limits }

…

On Sat, 5 Jul 2025 at 17:01, Jorge Mireles ***@***.***> wrote: *jorgeluismireles* left a comment (vlang/v#24850) <#24850 (comment)> The error for your code is: message: array.get: index out of range (i,a.len):0, 0 I think the initial problem is to permit to compile an array3 even with large sizes (how to know how big is array2 though is not mutable?) and it works when array3 is not used: const array1 = [1]const array2 = [array1]const array3 = array2[1000][1000] // <- does not complain at allfn main() { dump(array1) dump(array2) } [code.v:5] array1: [1] [code.v:6] array2: [[1]] — Reply to this email directly, view it on GitHub <#24850 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEEESAAKQYSNJLCQRIABAXT3G7ZFVAVCNFSM6AAAAACA3B5XK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMZZGI2DIMBVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jorgeluismireles]

V permits to have constants that can be modified (even they are "constants") after initialization using the values of another "real" constants. For instance in math module we have this:

pub const pi = 3.14159265358979323846264338327950288419716939937510582097494459
pub const pi_2 = pi / 2.0

But your constants are so intricate that show up a V bug. If you decide to pre-calculate constants since don't want the reader of them waits a lot of time every read, you could possible use statics precalculated by init functions with public access for read only. Check for ideas:

• https://docs.vlang.io/static-variables.html
• https://docs.vlang.io/v-types.html#fixed-size-arrays
• https://docs.vlang.io/modules.html#init-functions

[pd-giz-dave]

Thanks for your suggestions, but none of those are appropriate to my use case. Frustratingly, this issue only arose after I'd done a major re-factoring, this suggests the _vinit order can be manipulated, but all my experiments so far have failed.

…

On Sat, 5 Jul 2025 at 19:41, Jorge Mireles ***@***.***> wrote: *jorgeluismireles* left a comment (vlang/v#24850) <#24850 (comment)> V permits to have constants that can be modified (even they are "constants") after initialization using the values of another "real" constants. For instance in math module we have this: pub const pi = 3.14159265358979323846264338327950288419716939937510582097494459pub const pi_2 = pi / 2.0 But your constants are so intricate that show up a V bug. If you decide to pre-calculate constants since don't want the reader of them waits a *lot of time* every read, you could possible use statics precalculated by init functions with public access for read only. Check for ideas: - https://docs.vlang.io/static-variables.html - https://docs.vlang.io/v-types.html#fixed-size-arrays - https://docs.vlang.io/modules.html#init-functions — Reply to this email directly, view it on GitHub <#24850 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEEESAFOSJNK3E4PLN6PFIL3HAL7HAVCNFSM6AAAAACA3B5XK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMZZGYYTQNZSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jorgeluismireles]

Another approach is to convert the constant into a function, this:

pub const blobs_edge_limits = build_limits(0, 3, 5)

into this:

pub fn get_blobs_edge_limits() []u8 {
	return build_limits(0, 3, 5)
}

Don't think every call last too much as to need to pre calculate the value. An in extreme case another part of the program can cache the value for later use.

[pd-giz-dave]

Wow! Fixed so quick. As imptressive as ever. Many thanks.