fix #10073

[timotheecour]

• fix can't build a tuple with static int element #10073

links

• incorrect conversion from static int when used in tuple #9043 and PR Fix for VM codegen with static[T] types #9046

[timotheecour]

looks like this PR helps a bit, but still fails in following case:

proc foo[N: static int](dims: array[N, int]): auto =
  const N1 = N
  let temp = N # works
  let temp2 = (a:N)
  temp2

echo foo([1, 2]) # now is ok
doAssert foo([1, 2]) == (a:2) # Error: type mismatch: got <tuple[a: static[int](2)], tuple[a: int]>

couldn't we make static convert to something else (const??) as soon as it's instantiated, to avoid special casing it everywhere via skipTypes in this PR as well as in #9046 ?

[Araq]

static T needs to be removed from the language IMHO. Just allow to pass integer values as type parameters turning the value N into range[0..N-1] would allow almost the same patterns without this never ending clusterfuck of bugs, edge cases and downright unspecified behaviour.

[timotheecour]

static T needs to be removed from the language IMHO

=> we can discuss that here: https://github.com/nim-lang/Nim/issues/10085

[timotheecour]

/cc @Araq
PTAL, this unblocks #10070 and #10010

removing the WIP label to unblock this PR, the workaround for clients is simple enough (add const N1 = N for a static param N), and the other issue mentioned above in #10080 (comment) is pre-existing.

[timotheecour]

ping @zah or @Araq

[Araq]

That doesn't help much.

1. It is not clear that static T within a tuple should be allowed.
2. It is not clear that the codegens can deal with it.

[timotheecour]

That doesn't help much.

that unblocks #10070 (otherwise I'd need to change the test )
EDIT: I've changed the test in ./tests/vm/tissues.nim to unblock that PR

It is not clear that static T within a tuple should be allowed.

there's a test that relies on it, see #9046 (./tests/vm/tissues.nim) added by @LemonBoy
seems also rather arbitrary to disallow static T within a tuple /cc @zah

It is not clear that the codegens can deal with it.

not sure I understand that point; I assumed by the time it reaches codegen, static[T] would already be converted to T ; CI should already cover this I believe

[Araq]

not sure I understand that point; I assumed by the time it reaches codegen, static[T] would already be converted to T ; CI should already cover this I believe

But static T object/tuple fields should be optimized away since they don't contain any runtime values...

[timotheecour]

But static T object/tuple fields should be optimized away since they don't contain any runtime values...

I still dont' understand; how is that different from behavior of const or static in example below, where it doesn't get optimized away since let a = (...) tells the compiler to convert them to a runtime value?

const Foo1 = 10
proc fun(foo4: bool, Foo5: static bool) =
  const Foo2 = 11
  let foo3 = 12
  let a = (Foo1, Foo2, foo3, foo4, Foo5) # works
  echo a

fun(true, true)

the expression in which static is used should dictate whether it should get converted to a runtime value or not

[zah]

A more proper fix has been pushed here: #10218

[timotheecour]

thanks a bunch @zah I verified it also passes this: #10080 (comment) ; closing this in favor of your PR