If I understand the example code correctly, it's modifying a heap-allocated struct that's pointed to by a global const. So the global const contains an address which is not modified, but the thing at that address is modified. Right?
What does the intended behaviour (after the fix) look like? Are mutable fields in structs disallowed if the struct is pointed to by a const?
V has global consts, they are immutable, but can be initialized with complex expressions, for example
`const x = foo()`
There's a bug that allows to trick the compiler and modify the const via another variable, it's a one line fix, and will be fixed today.
Global mutable variables are only allowed with `-enable-globals` and are supposed to be used only in low level code, like drivers and kernels.
If I understand the example code correctly, it's modifying a heap-allocated struct that's pointed to by a global const. So the global const contains an address which is not modified, but the thing at that address is modified. Right?
What does the intended behaviour (after the fix) look like? Are mutable fields in structs disallowed if the struct is pointed to by a const?
After the fix it's not allowed to do
`mut x := immutable_var`
How's that "one line" fix in the type checker coming? Looks like it wasn't fixed yesterday.
It was fixed, but you keep fighting your fight. I'm sure there's another bug you can find to spread the "V is scam" message.
2 replies →