Aliases for slash commands?

[Paillat-dev]

Feature Request

Having slash command aliases, meaning you can use multiple names for one slash command

Rationale

Multiple users have been asking about this, in the official server, as well as in other places. In my opinion, it feels weird for the end user no to have the possibility to use aliases= in slash commands. Notably, when switching to slash commands from prefixed, it is one lost feature, and NOT ONLY for the library user, but also for the related bot's end user, as their shortcuts and muscle memory will be lost in slash commands. Sometimes, aliases not only allow shorthand, but also completely different command names, and in both cases, autocompletion is not always enough.

This would also allow for bette compatibility between slash and prefix with bridge (which is also being partially rewritten afaik) as the alias parameter would not be ignored by slash commands. This would feel more intuitive in my opinion.

I am a strong defender of slash commands, and often only use them, however, I myself feel like this feature is missing sometimes as well.

Implementation

Here are, after discussing with others, possible implementations, which are not exhaustive:

1. Literally duplication slash commands: this would create multiple identical slash commands (with the same callback) and a different name. It is nowhere the ideal solution, nor my favourite, but mention it nonetheless. While it would be the most ideal and intuitive solution, it would probably flood the slash command menu, and create unnecessary complexity for the end user.

2. Leveraging the command description autocomplete: This would insert the different aliases at the end of the slash command's description (i.e. ",".join(aliases)). Since discord uses the command description for the autocompletion of the slash command menu, it would technically work, and the use would (most often) be proposed with the correct command for a given alias. It is less direct and "logical" than the first proposition, but doesn't have its downsides either, and is a good compromise in my opinion

3. Both?: This would literally be to give the use the choice for "real" and "fake" aliases and is more a troll proposition than anything imo but I put it anyways.

Challenges

Challenges not to overlook are the following

1. For option 2, there is a description max length.
2. Command groups might cause some problems
3. Documentation, this would need to be clearly documented, so that users clearly understand what is being done under the hood, who, and why,
4. Anything else? For sure, but couldn't think of it.

[JustaSqu1d]

I propose the exact wording for the second option to be " (i.e., , , ...)"

[Paillat-dev]

github removed it but he said "<command description> (i.e., <alias1>, <alias2>, ...)"

[Paillat-dev]

I mean yeah I think that is a good solution. I am willing to pr this, just, want to get confirmation from someone. Also maybe it is better to wait for completion of the bridge stuff?

And if someone could untimeout me in the server that would be fabulous.

[ChickenDevs]

Personally, I like the second option as well.

(Basically taken from your challenges section, just restating these for importance)
If we do go that route, we need to make it very clear in the docs that the aliases attribute will append onto the end of your command's description. We also need to account for what our fail-condition will be if the slash command character limit is exceeded.

From https://discord.dev/interactions/application-commands#slash-commands

Slash commands can have a maximum of 8000 characters for combined name, description, and value properties for each command, its options (including subcommands and groups), and choices.

[Paillat-dev]

Also, Luma suggested that the system might only publish that part of the description to discord, but wouldn't actually add it to the description attribute.

Related to what you said, yes, it should definitely be well documented, people need to understand that it is not a one to one replica.

[plun1331]

I think if we want to go this route we might just be better off suggesting it to users instead of doing it in the library