Use int64 instead of int for numbers.

[roosmaa]

Currently it's impossible to safely Encode/Decode int64 IDs unless all involved systems run on a 64bit machine where int data type is 64-bit. Hashids libraries in other languages (checked C#, JS) seem to support 64bit IDs.

This PR changes the []int to []int64 everywhere. All tests pass. However, since it changes the signature of the Encode/Decode functions all users of this library have to migrate their code manually.

[speps]

That's a good change. However, can you make it so the Encode/Decode with int64 are now EncodeInt64/DecodeInt64 and keep the original signature (with an implementation which converts to/from []int then calls the Int64 variants). That way the API is the same for existing users, but you can use int64 if needed as well.

Also, the current tests don't go over the limits, it would be good to add tests with numbers between 32 bits and 64 bits to ensure they can be properly encoded/decoded without loss of data.

I'll merge your pull request if you can do that. Thanks.

[roosmaa]

Good idea. I added EncodeInt32/DecodeInt32 convenience functions as well, while I was at it.

[speps]

That might be a bit redundant. I prefer APIs where there's not much duplication :)

[roosmaa]

Ok, no EncodeInt32/DecodeInt32 then :sunny:

[roosmaa]

Anything else I can improve here? :mag:

[roosmaa]

Updated comments, renamed variables.

[speps]

Thanks, I'll do a final check tonight and merge :)

[roosmaa]

... ?

[speps]

I'm sorry I didn't have the time to check yet. What I wanted to check is if the new code returns the same values as the old code, something which isn't actually tested for now (so I wanted to add tests as well). If you're up for it, you can add those tests :) It would just compare the returned string against a known one (generated with the PHP or JS version of the algorithm for example).

[speps]

Done :)