Add number to ApplicationCommandOption

[Splingush]

Hello!

This commit adds NUMBER to the ApplicationCommandOption.
It also adds a method to the builder for adding it as a choice.

[Splingush]

Any double between -2^53 and 2^53

Not sure if one should enforce the range in the library, when adding options.

It does cause an issue when a choice of a larger number, e.g. 2.0f64.powi(53) + 1111., is being added. Discord accepts the slash-command to be created, but afterwards when the interaction is received it will throw an error here:

'called Option::unwrap() on a None value'

Discord handles larger doubles in their frontend, so receiving it from user-input is not an issue.

I could change the add_number_choice to include a check. It's an additional method, would returning a Result be fine? It will be different from the other add_choice-methods then.
A newtype that wraps double that can only be in this range could be another possibility.

[HarmoGlace]

In my opinion, you should not change your actual implementation to add some checks in the builder. It would be inconsistent, as for instance you can provide strings which are considered as invalid by discord but not by the library.

However you can also choose to make your own type, even if I think that it wouldn't be very useful.

[Splingush]

Yeah, the add_int_choice has a similar issue. It does not let you utilize the full range of (-2^53; 2^53), because it takes an i32 (receiving it uses i64).

I think with the strings you would get an api-error (invalid-form) or it fixes it silently (I think with emoji-names?), but with the number here it fails silently and can cause an issue later on.

I would be all for enforcing it in the library, but I'm not sure if it's feasible with keeping it up to date. For example, the embed-description-limit was raised from 2048 to 4096 recently, which is only noted in the docs (which needs updating as well.)

I can just add a note about the current limit to the method, if you want.

[HarmoGlace]

Well it is a discord issue if their API accepts an invalid number, it should be reported. A silent fail isn't good I agree

[Splingush]

Hey, sorry for reopening, but I looked a bit more into it, and Discord is returning a string instead of a number when the choice-value is too large. So it could possibly be handled. But as it's outside of the documented supported range, it's undefined behaviour.

Funnily enough, if I create this command with the too-large number-choice in a different library (discord.js), I get an error when selecting the choice in the Discord-UI, so a user-facing error:

Application command interaction option values must be of type string, integer or boolean

I don't know why this is different, but that's even worse.

---

Well it is a discord issue if their API accepts an invalid number, it should be reported. A silent fail isn't good I agree

I think it was already discussed in the discord-api-docs-repo in several issues, so I don't think there is much use in asking them to reject these inputs.

Should I add handling for the string-case? Or is it fine to keep it the way it is? If the latter, please close again, and thanks for the guidance 👍