Mirror of forum.nim-lang.org

2288 :: Static var declarations

• mbaulch (orginal) [2016-05-29T11:49:29+02:00] view original

  Two attributes of Nim particularly appeal to me. Namely, it

  • allows easy deployment across many platforms, including those with a very low memory footprint, and
  • provides (in most cases) a drop-in replacement for C

  Nim achieves these (and many other) goals spectacularly, and falls short in very few places. I'd like to address one (in my view) minor shortcoming.

  My proposal is that, in addition to the var statement, we allow a static var statement, similar to the concept used in C.

  
  proc id(): int =
    static var nextId = 0
    inc(nextId); nextId
  Run

  could be transformed to

  
  var nextId_X = 0
  ...
  proc id(): int =
    inc(nextId_X); nextId_X
  Run

  where X is chosen so as to avoid name conflicts. I suppose the compiler could:

  • issue a warning when static var is used in a global context
  • disallow the noSideEffect pragma for procs containing such a declaration.

  Of course, the syntax could be modified from that described above.

  The Nim compiler (for instance) uses many global vars. I haven't checked them all, but my random sample suggests quite a few are used in only one proc. I'm sure lots of other Nim code (including my own) is similar. I contend that restriction of variable scope, and declarations made close to call-sites are unequivocably a good thing!

  I've searched in the obvious places, but I can't find any reference to a discussion about such a feature for Nim.

  What do others think? Is this a feature that could benefit Nim? If someone (myself? another volunteer?) were to implement it, is it likely to be accepted into the language?

  Thanks

---

• flyx (orginal) [2016-05-29T12:00:48+02:00] view original

  This is already possible, see here:

  proc id(): int =
    var nextId {.global.} = 0
    inc(nextId); nextId
  Run

---

• mbaulch (orginal) [2016-05-29T12:12:16+02:00] view original

  I obviously overlooked it, despite reading the manual closely many times. It seems strange that it's classified as a pragma, as it causes fundamental changes to semantics.

  Thanks very much. I'll have a play with it.

---

• Stefan_Salewski (orginal) [2016-05-29T12:55:36+02:00] view original

  For me it was not really obvious if global pragma would make the variable really visible in global name space, what we may want to avoid. So I had to test -- and indeed it is only visible inside the proc, not in global name space :-)

---

• OderWat (orginal) [2016-05-29T16:57:04+02:00] view original

  I think the pragma should be renamed to static.

---

• Krux02 (orginal) [2016-05-29T20:56:29+02:00] view original

  I don't think it should be named static. It anything, then globalLifetime or something like that. Static was chosen in C for the reason that at the point they wanted to introduce this feature, the keyword static was already available, and did not yet have any meaning in that context.

---

• Varriount (orginal) [2016-05-29T22:39:06+02:00] view original

  Maybe "persist" then? It's a variable whose value persists beyond the function call.

---

• Araq (orginal) [2016-05-29T22:51:22+02:00] view original

  In other words it has global lifetime. ;-)

---

• OderWat (orginal) [2016-05-29T23:15:05+02:00] view original

  Yes global lifetime.. but not global visibility. Thats the reason the name should change :-P

---

• cdunn2001 (orginal) [2016-05-30T19:50:31+02:00] view original

  I think global is fine, as long as the documentation clarifies that it's for "lifetime", not "visibility".

---

• Araq (orginal) [2016-06-02T16:45:04+02:00] view original

  Er, but Nim already has static and it means "eval at compile-time".

---

• OderWat (orginal) [2016-06-02T17:24:34+02:00] view original

  Well.... either one calls the pragma static nonetheless or leave it as "global" and extend the documentation with a phrase like "this is what static does in C and other languages". maybe even add "static variables" to the doc and point it to the global pragma then.

  EDIT: Can we rename {.compiletime.} to {.static.} then? :-P

---

• cdunn2001 (orginal) [2016-06-03T09:15:50+02:00] view original

  +1 for {.persist.}

---

• timothee (orginal) [2018-04-10T22:33:28+02:00] view original

  ping: what's the conclusion on this?

---

• cdome (orginal) [2018-04-10T23:46:49+02:00] view original

  please stop pointless renaming, it just breaks backwards compatibility. Implement something new for Nim instead.

---

• timothee (orginal) [2018-04-11T00:12:20+02:00] view original

  I was just asking for what's the conclusion on how to define static shared global variable, I guess it's:

  proc isHexNumber(s: string): bool =
    var pattern {.global.} = re"[0-9a-fA-F]+"
    result = s.match(pattern)
  Run

  (ie in D, __gshared pattern = ...)

---

• rforcen (orginal) [2021-08-05T10:10:14+02:00] view original

  found this specially useful in opengl draw hook proc and other {.cdecl.} where using parameters is not supported.

  proc display() {.cdecl.} =

  ...

  glutDisplayFunc(display)

---

• rforcen (orginal) [2021-08-05T10:10:38+02:00] view original

  found this specially useful in opengl draw hook proc and other {.cdecl.} where using parameters is not supported.

  proc display() {.cdecl.} =

  ...

  glutDisplayFunc(display)

---

• rforcen (orginal) [2021-08-05T10:11:06+02:00] view original

  found this specially useful in opengl draw hook proc and other cdecl where using parameters is not supported.

  glutDisplayFunc(display)

---