The one that's a thread is the one that has a table parameter.... There are two not-entirely-orthogonal questions here:
1\. What's more important to emphasize? That's the thing we work on is thread code, oh, and it's a proc rather than a variable? Or that we're going to define a proc. Oh, and it's intended to run in its own thread?) Well, that obviously depends on your specific circumstances, and in the proc() case I might agree that the attributes (side effects, thread, async, ...) are as important as this being a proc, though no more important. In the case of variables, though - I totally disagree; the name is the most important thing (given that Nim chose suffix everything unlike C) -- see e.g. [https://github.com/captainbland/nim-validation](https://github.com/captainbland/nim-validation) for example (and there was a DAL/ORM with similar good use, but I can't find it now). I had used prefix annotations in C# when using WCF and stuff, and even people who like C# (I don't) said it sucked. So, unless you think you should have annotations before for procs and after for vars, I think after wins. 2\. What are you used to? Well, this is totally subjective; I'm used to both, and have no preference for procs (but the preference I stated above for vars) and do have a preference for uniformity. And I offer again: If "thread" or "async" is the important character - use a macro to make a thread_proc or async_proc the same way func makes a "nosideeffect" proc; no need for language changes for that. The only language change that might make sense that I can think of (and perhaps everyone happy) is {.next_is thread}, which is like {.push thread} wiith automatic pop at the end of the scope; But I really think that this discussion should only be carried if you've _tried_ to get used to suffix for a while and couldn't -- not because it looks weird at first. Have you tried?
