Nim v2: what would you change?

Alright, I went through the thread and compiled summaries of all the suggestions into a Gist: I did a best-effort attempt to break suggestions up by needing breaking changes or not: but if I categorized any wrong (or misrepresen

Why I left the Nim community

This is the first I heard there is a Nim fork. It's not a bad sign. Another language I often use is awk and that has dozens of varieties since its creation in the 1970s. The One True Awk is the version specified in `The AWK Programming Language`, by Aho, Kernighan, and Weinberger. For a long tim

C++ copy-constructor issue when using {.constructor.} pragma

Since `s` is a global variable, it becomes a C global which has to be initialized in `NimMain`. Try using a local variable instead.

Nim v2: what would you change?

Is there someone compiling all the nice suggestion made here or is this just wishful thinking (aka pissing in the wind) ?

Nim v2: what would you change?

Pretty minor thing compared to some of the stuff here: I really like using Nim's UFCS to chain together calls, but this currently doesn't work well when I need to disambiguate by module. Eg: `foo.bar.baz.quux` works until I import a module with a conflicting function name. The obvious extension

Weird behaviour from fmt in strformat library

It does apply, just in a different way. `fmt` is expanded _[after](https://forum.nim-lang.org/postActivity.xml#after) the template itself is expanded, and templates are hygienic by default, so `attempts` will be gensym'd so fmt can't find it. You can solve this by using `inject`, but then `atte

Weird behaviour from fmt in strformat library

There's no difference in how `var`/`let`/`const` are treated in templates, in fact `let` and `const` are also called "variables" as well as `var` :)

Weird behaviour from fmt in strformat library

The inject pragma works, thanks @DavideGalilei and @Yardanico. By the way is this specific to variables or does it also affects let and consts

Weird behaviour from fmt in strformat library

The variable attempts which the compiler claims is undefined is not part of the template arguments. it's a local variable declared inside of the template. So that limitation does not apply to this block of code

Weird behaviour from fmt in strformat library

This template gives an error at the line where fmt is to be used to format a string with the keyword attempts template requestWrapper(client : HttpClient, url, body, status: string, headers: TableRef[string, seq[string]], reqtype : ReqType = Get, action: untyped) =

Weird behaviour from fmt in strformat library

When is substitute fmt for format from the strutils library it works well. I think the problem is from the way the fmt macro builds code. maybe it's ignoring the attempts variable while building the code

Weird behaviour from fmt in strformat library

This is intended behavior, see

C++ copy-constructor issue when using {.constructor.} pragma

I've imported a C++ class that has a deleted `=operator` and created a Nim procedure to instantiate the Nim wrapper for the C++ class. The deleted `=operator` means Nim's default code generation that uses the copy constructor will need to be changed out. The `constructor` pragma has been applied

Trojan:Win32/Wacatac.B!ml

This is the reason I had to stop using nim for anything related to windows. It's sad, but it's true that both nim compiler and compiled binaries are flagged as trojans. It's I matter I can't play with and immediately stops the use of nim in business. Luckily I can still use it on Linux, but the

CLOEXEC on old Linux kernel.

If whatever is opening the socket is setting, CLOEXEC it doesn't expect to have to close the socket (see [here`](https://github.com/nim-lang/Nim/blob/927978345bbf57631828287850eda13b82277eb7/lib/pure/asyncdispatch.nim#L1585) so I don't think setting it to 0 will be enough

CLOEXEC on old Linux kernel.

After reading some Nim code from stdlib, I think I can get away by defining SOCK_CLOEXEC to 0. What do you think? I could pass -DSOCK_CLOEXEC=0 to a C compiler, but I was thinking if I could do it using Nim. I've created fixups.nim file with: > {. emit(""" > > #ifndef SOCK_CLOEXEC > #defin