modn API inconsistency

[axic]

All mod/div methods return a BN instance, except modn which returns a JS Number.

I think it would make sense making the current modn internal (prefixing it with _) so that toString can keep using it the fastest way, and creating a new modn which returns a BN instance.

divmod already encapsulates a modn result as a BN instance so it should use the new method.

Comments?

[indutny]

I'm fine with fixing it, but let's postpone it until next major release.

[axic]

When do you plan a new major release? Should this live in a branch until then? Or shouldn't we have a branch called v5.x so changes like that can be merged in there?

[indutny]

Hm... I'm not sure about it yet. Do you think there is some urgency in handling this particular issue? Or do you have any other plans in mind?

[axic]

Don't know, there could be a couple of things made more clear, etc.

• Renaming strip() to _strip() is a breaking change too (readme: document strip() and toJSON() #105)
• Maybe reviewing the constructor method(s) could lead to such a change (see Reject decimal input #91)

[jprichardson]

According to https://github.com/indutny/bn.js#postfixes, any method ending with n returns a JavaScript number. Why change that here? Wouldn't that be confusing? ping @calvinmetcalf

[indutny]

@jprichardson this is not exactly true. n applies only to argument, it does not say anything about return value. For example .iaddn returns BN.

[jprichardson]

n - which means that the argument of the function must be a plain JavaScript number

@indutny Gahhh. Haha, it says "argument" right there - sorry I missed that.

[axic]

All the arithmetic methods return a BN except modn. Perhaps it could be a good idea to agree on a prefix or suffix for those which don't and have that as a counterpart for modn after the breaking change?

[indutny]

I can't really think about anything other than rn? Like returns number.