Autocomplete support has been removed in twilight-interactions 0.10 because the existing implementation was incorrect. It is necessary to re-implement this feature in a next release.

The main difference with regular command models is that autocomplete models receive partial and not validated data. In fact, some validation is performed client-side, but all fields, no matter their type, are sent by Discord as strings. Furthermore, all fields should be considered as optional except the current focused field.

Proposed implementation

The implementation that seems most suitable is the creation of a new AutocompleteModel trait with associated derive macros. This trait would allow creating models of autocomplete interactions, with the support for a focused attribute that specify which field expect to be focused (optional). It is also necessary to support subcommands.

#[derive(AutocompleteModel)]
pub struct HelloCommand {
    user: Option<String>,
    #[command(focused = true)]
    message: String,  // Not wrapped into an Option because it is the focused field
}

#[derive(AutocompleteModel)]
pub enum SubCommand {
    #[command(name = "hello")]
    Hello(HelloCommand),
}

This implements CommandOption for Id<AttachmentMarker, since Attachments are now valid for slash commands, to bring this once again up to parity with twilight itself.

This also makes the test pass in the simplest way possible, just by making an empty HashMap.

so in an option like

#[command(desc = "foo", min_value = 1, max_value = 20)]
num_option: i64

isn't it unnecessary to use i64 since the value cant overflow?

This seemed to be a very simple upgrade, and I wanted to get my bot upgraded, so I'm submitting this PR :3

cargo nextest saw the tests run well, and after I enabled actions in my fork that worked fine too.

note: it seems I accidentally edited a line in the readme; my markdown formatter doesn't like your markdown formatting (I use vscode and Markdown All In One + markdownlint)

Actually, additional settings like channel_types are supported with the CreateCommand trait, but are not enforced when parsing command data. These settings should be provided to the from_option method of the CommandOption trait, which will introduce a breaking change.

User choice can be limited to a set of values for STRING, INTEGER and NUMBER option types. New CommandOption and CreateOption macros will be introduced to parse these options as enums.

Example usage

#[derive(CommandOption, CreateOption)]
enum Color {
   #[option(name = "Red", value = "red")
    Red,
   #[option(name = "Blue", value = "blue")
    Blue,
   #[option(name = "Green", value = "blue")
    Green
}

The displayed name is specified with the name attribute (string) and the value with the value attribute (string, int or float). The name attribute will be required only if CreateOption is derived.

Create derive macro for the CreateCommand trait. This will introduce a #[command] attribute. All struct fields must be documented (doc comment or desc attribute).

use twilight_interactions::{CommandModel, CreateCommand, ResolvedUser};

/// Say hello with a message
#[derive(CommandModel, CreateCommand)]
#[command(name = "hello", default_permission = true)
struct HelloCommand {
    #[command(desc = "Your message.")
    message: String,
    /// The member to send the message to.
    #[command(rename = "member")
    user: Option<ResolvedUser>
}

This PR makes it possible to have Cow fields in types that derive CommandModel and CreateCommand.

The main use-case that comes to mind is that it simplifies combining slash commands and prefix commands. Upon invocation of a prefix command, people can parse the message content into the CommandModel types and by using Cow, message content does not have to be cloned but can just be given as reference instead.

Depends on #10

Modal support would be really convenient. A basic struct for modals would be great.

#[derive(ModalDerive)]
#[modal(title="my modal's title", custom_id="this_will_be_used_in_the_parser_too"]
struct MyModal {
    // The fields will automatically get wrapped with actionrows maybe?
    #[modal_field(custom_id="foo", label="Foo", value=1_u8, type=select_menu)]
    my_modal_field: u8,
    #[modal_field(custom_id="bar", label="Bar", max_length=20, text_input_ style=short, type=text_input)]
    my_text_input_field: String
}