len of array with function calls should not be constant

[thehowl]

// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
	const a = len([1]int{
		func() int { println("hey!!"); return 1 }(),
	})
	fmt.Println("Hello", a)
}

this code fails in the go playground, because a is not a constant expression:

The expression len(s) is constant if s is a string constant. The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain channel receives or (non-constant) function calls; in this case s is not evaluated. Otherwise, invocations of len and cap are not constant and s is evaluated.

however, it is correctly parsed and succeeds in gno.

related #3600

[jaekwon]

Isn't this supposed to be picked up by the typechecker?

[thehowl]

Deferring to post-mainnet launch, as this code is rejected by the type checker, and thus not accepted on-chain:

$ cat a.gno
// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
        const a = len([1]int{
                func() int { println("hey!!"); return 1 }(),
        })
        fmt.Println("Hello", a)
}
$ gnox tool lint a.gno
.: parsing gno.mod at .: gno.mod file not found in current or any parent directory (code=1)
a.gno:8:12: len([1]int{…}) (value of type int) is not constant (code=4)
exit status 1

We can push back into mainnet launch if there is any code related to this go that fails in Gno, but is expected to succeed.

[Kouteki]

Thank you for working on this, but let's not merge it. This seems to be an issue with Go more than Gno, and an issue because it isn't useful to declare things in a len() or cap() which will discard what is inside anyways.

We should just make sure the go type-checker is used to filter these, and they can be rejected, but Gno itself can and should evaluate these just fine as is. No need to complicate Gno code to adhere to Go's warts.

#3714 (comment)