> I don't think your code is standard though, usually void are implicit in the > return type, also var are used for in-place mutation, not pointers.
Thanks for letting me know, I haven't written a lot of Nim so I'm still learning. I didn't realise that using var means in-place mutation, I've changed it and now I know that it doesn't copy arrays I'll use it going forwards. > And it's probably much more likely to read from an immutable value (often an > int or byte array) to a mutable value (often a byte array or an int), so a > proc with 2 inputs is more convenient that one that requires a copy before > use. I like to force people to explicitly copy things so that they know it's being copied. > Also your library doesn't abstract away "readBytesBE"/"writeBytesBE" which > would autoswap on little-endian architecture or be a no-op on big-endian, and > equivalent for little-endian operations. That's ntoh and hton, I've just changed the if statements to when \- I just realised that I can use compile time conditionals for this since cpuEndian is an enum so it's a no-op for the respective cases. > hton , ntoh are inheriting bad unix naming in my opinion. Many people are familiar with those functions, I decided to write functions that mirror them but were more user friendly, so you enter the basic type you want converted into the function rather than pointers and it converts the data in the way the api people are familiar expect. This is a time when there are many new programming languages around sometimes competing for the same _" mind share"_, some familiar interfaces for programmers makes adoption easier. > For working with endianness this has a better explicit and generic API, and > is heavily tested in non-trivial projects including networking, big integers > and cryptography: > [https://github.com/status-im/nim-stew/blob/master/stew/endians2.nim](https://github.com/status-im/nim-stew/blob/master/stew/endians2.nim) Thanks for your helpful comments, I'll take a look at your library.
