[ENHANCEMENT] Implement From<T> for UrlParts enums

[russcam]

Each API models the API url parts as an enum, and where an API has more than one enum variant, the API function on the root/namespace client takes the enum as an argument. For example, for search

let response = client
    .search(SearchUrlParts::Index(&["index-1"])) // <-- accepts enum
    .send()
    .await?;

Currently, the Rust compiler cannot infer the enum type based on the parameter, meaning the complete enum path needs to be specified as above, instead of simply the following pseudo

let response = client
    .search(Index(&["index-1"]))
    .send()
    .await?;

To make the API somewhat simpler to use, it is proposed to implement From<T> traits for each enum such that a value, or tuple of values, can be used. Taking the example above

impl<'a> From<&'a [&'a str]> for SearchUrlParts<'a> {
    fn from(index: &'a [&'a str]) -> Self {
        SearchUrlParts::Index(index)
    }
}

impl<'a> From<(&'a [&'a str], &'a [&'a str])> for SearchUrlParts<'a> {
    fn from(index_type: (&'a [&'a str], &'a [&'a str])) -> Self {
        SearchUrlParts::IndexType(index_type.0, index_type.1)
    }
}

let response = client
    .search(&["posts"].into())
    .send()
    .await?;

[mwilliammyers]

I was thinking the exact same thing when I was reading the docs.

Should we go a step further and have search accept an Into<SearchUrlParts<'a>>?

Also, what should we do when the variants are the same type?

[russcam]

Should we go a step further and have search accept an Into<SearchUrlParts<'a>>?

👍 to this

Also, what should we do when the variants are the same type?

As far as I am aware, I think there are only a few APIs where the enum variant to construct from a passed tuple of values is ambiguous

• NodesInfoParts:

  elasticsearch-rs/elasticsearch/src/generated/namespace_clients/nodes.rs

  Lines 214 to 223 in 76d5c2e

  	pub enum NodesInfoParts<'b> {
  	#[doc = "No parts"]
  	None,
  	#[doc = "NodeId"]
  	NodeId(&'b [&'b str]),
  	#[doc = "Metric"]
  	Metric(&'b [&'b str]),
  	#[doc = "NodeId and Metric"]
  	NodeIdMetric(&'b [&'b str], &'b [&'b str]),
  	}

• NodesStatsParts:

  elasticsearch-rs/elasticsearch/src/generated/namespace_clients/nodes.rs

  Lines 527 to 540 in 76d5c2e

  	pub enum NodesStatsParts<'b> {
  	#[doc = "No parts"]
  	None,
  	#[doc = "NodeId"]
  	NodeId(&'b [&'b str]),
  	#[doc = "Metric"]
  	Metric(&'b [&'b str]),
  	#[doc = "NodeId and Metric"]
  	NodeIdMetric(&'b [&'b str], &'b [&'b str]),
  	#[doc = "Metric and IndexMetric"]
  	MetricIndexMetric(&'b [&'b str], &'b [&'b str]),
  	#[doc = "NodeId, Metric and IndexMetric"]
  	NodeIdMetricIndexMetric(&'b [&'b str], &'b [&'b str], &'b [&'b str]),
  	}

• NodesUsageParts:

  elasticsearch-rs/elasticsearch/src/generated/namespace_clients/nodes.rs

  Lines 784 to 793 in 76d5c2e

  	pub enum NodesUsageParts<'b> {
  	#[doc = "No parts"]
  	None,
  	#[doc = "NodeId"]
  	NodeId(&'b [&'b str]),
  	#[doc = "Metric"]
  	Metric(&'b [&'b str]),
  	#[doc = "NodeId and Metric"]
  	NodeIdMetric(&'b [&'b str], &'b [&'b str]),
  	}

In these cases, I would propose choosing the more common variant?

[russcam]

Started looking at this in enhancement/24 branch.