> Curious why this is the case? I know of no reliable statistics about `global` vs `thread local` in the real world, but "thread local" is harder to support for the more foreign targets (there is this whole `--tlsEmulation:on` feature...)
> if the reason is it'd prevent common idiom var count3 = 3 (which currently > errors as: "Error: a thread var cannot be initialized explicitly; this would > only run for the main thread"), this could be fixed. True but it introduces too much runtime machinery for my taste. Good code evolved to use explicit passing of parameters, so neither thread local nor shared variables are common anymore (ymmv). But if a global is needed it's usually for some configuration stuff that is shared across threads making `global` the better default. But you can argue either way, Nim's `.gcsafe` design certainly pushes one to use thread local storage. Which sucks for the logging module at least...
