Circular imports break global init order

[arnetheduck]

testit:

proc init(): string =
  echo "init a"
  "a"

proc f*() =
  echo "A"
  var a {.global.} = init()
  echo a

import testit2

f()

testit2:

import testit

proc init(): string =
  testit.f()
  echo "init b"
  "b"

proc f*() =
  echo "B"
  var a {.global.} = init()
  echo a

f()

A

init b
B
b
init a
A
a

notice how nothing is printed after the first A. This issue is the non-generic version of #17087 and of course is logically unsound due to the circular dependency - global inits are not sound to use in this context - as such, it would be good for the language to limit their capabilities - imports like this happen in the wild and are incredibly hard to find.

[Araq]

Can't we deprecate .global altogether? It's quite unuseful in a world of multiple threads...

[zah]

.global. is usually used to create associations between types and values such as RTTI information. Since constants and variables cannot be generic and instantiatable in the same way functions are, if you want to create an abstraction where you need "one value per type", your only solution is to define a generic function that declares a .global. variable.

It would be possible to deprecate these globals only if Nim provides an alternative mechanism having the same capabilities. One can imagine having generic constants for example:

const Foo[T] = createCustomRttiInfo(T)

Other similar use cases from our code base are "one value per metric name", "one value per logging topic name", "one value per source location", "one value per symbol" and so on.

[Araq]

But this doesn't explain why these globals need to be initialized before other globals.

[arnetheduck]

well, in C++ the above actually has a well-defined order of initialization because the globals (static locals) are lazily initialized. Fixing it this way would be a backwards-incompatible change however, because the side effects of init would happen in a different order throughout - unless of course the current behavior in the language can be considered undefined?

[arnetheduck]

it's also "interesting" that the global is initialized even if the function is not run:

import testit

proc init(): string =
  testit.f()
  echo "init b"
  "b"

proc f*() =
  echo "B"
  var a {.global.} = init()
  echo a

if false:
  f()

in this case, init b is still printed, even when testit2.f() doesn't actually happen.