Alternative 2: Suffix renamings (_n suffix)

[minad]

alternative to #437

[minad]

Is this _n suffix acceptable for you? The root function was called n_root before. I think the _d suffix should be reserved for digits.

[nijtmans]

Yes, the 'n' suffix is OK to me. As type, I would prefer 'unsigned int' or 'unsigned long', since 'n' suggests a positive number: I don't want to check for n < 0 in every function, returning MP_VAL in this case. But ... that's OK for another PR

[minad]

Yes, we also had the unsigned discussion in #437. Let's keep things separate.

[minad]

@sjaeckel I guess you prefer this over alternative 1? Ready from my side.

[sjaeckel]

@sjaeckel I guess you prefer this over alternative 1? Ready from my side.

I am not sure, that's why I left them both untouched. Does this block you?

[minad]

This is not a big blocker. Maybe a bit for #430. But at at some point we have to resolve this.

[sjaeckel]

Okay, so you think we should go with this version?! :)

I'm fine with this version of the API.

Now let's head for 2.0 with this version as there are still some discussions upcoming e.g. regarding unsigned arguments.

[minad]

I don't really care, but having it like this leaves the door open for all-mp_int functions.

[minad]

This is for 2.0. but we should backport the renaming/deprecation. That's all for 1.x

[minad]

Now let's head for 2.0 with this version as there are still some discussions upcoming e.g. regarding unsigned arguments.

What do you mean by that? Can this be merged?

[sjaeckel]

Can this be merged?

as soon as it's rebased