Added cmpMem export

[planetis-m]

Currently there are zeroMem, copyMem, moveMem, equalMem but nimCmpMem is missing an export name.

[ringabout]

general style guide

see timotheecour#415

• code block => runnableExamples
• rst code blocks without a test => recommend using a test (eg :test: "nim c $1"; perhaps with :status: 1)
• proc + noSideEffect => func
• assert in a test file => doAssert
• isMainModule in stdlib => recommend moving to tests/stdlib/tfoo.nim
• double backticks => single backtick
• capitalize the first letter
• lots of testament specific checks (eg exitcode: 0 usually useless)
• etc, countless things that would be best done as a tool instead of relying on every reviewer to check all of those in every PR (plus for making it easier to improve stdlib + third party projects)
• check for presence of multiple yield statements in inline iterators, which cause code bloat
• see also: https://nim-lang.github.io/Nim/contributing.html#best-practices
• naming style https://nim-lang.github.io/Nim/nep1.html

[timotheecour]

instead of exporting a new symbol in system, how about creating a new low-level stdlib module std/memory (or maybe std/memutils) which can then grow as needed without being burdened by bloating system.nim?

(note, there's already system/memory.nim but it's considered "private")

As usual, code duplication can be avoided by using intermediate private modules, eg import std/private/x)

[timotheecour]

needs a runnableExamples + test in tests/stdlib/

[planetis-m]

runnableExamples doesn't work, I'm getting line 49: invalid identation

[timotheecour]

@planetis-m that's because you need = in proc declaration; followup PR welcome

[planetis-m]

That would refactor the system module, I guess there is a good reason it was written that way, if you need runnableexamples so bad you can try.

[timotheecour]

indeed, see nim-lang/RFCs#309

[Araq]

instead of exporting a new symbol in system, how about creating a new low-level stdlib module std/memory (or maybe std/memutils) which can then grow as needed without being burdened by bloating system.nim?

Yeah, I agree. However, this should be done later, for now it's conistent with copyMem and friends.

[planetis-m]

Thanks for the review everyone, I will address all your comments today (so don't merge yet).

[planetis-m]

instead of exporting a new symbol in system, how about creating a new low-level stdlib module std/memory (or maybe std/memutils) which can then grow as needed without being burdened by bloating system.nim?

(note, there's already system/memory.nim but it's considered "private")

As usual, code duplication can be avoided by using intermediate private modules, eg import std/private/x)

Can't work, I tried it and getting ambiguous calls. It would be a breaking change.