Impl `Type`, `Encode`, `Decode` for `AsRef<str>`

[malobre]

Currently postgres' Text (and other db equivalents) is compatible with:

• &'_ str
• String
• [&'_ str]
• [String]
• Vec<&'_ str>
• Vec<String>

Instead, I suggest implementing Type, Encode & Decode for:

• T: AsRef<str>
• [T] where T: AsRef<str>
• Vec<T> where T: AsRef<str>

This would simplify the code while allowing more types, such as Box<str> or Cow<'_, str>, to be used with Text.

I haven't taken a look at other SQL types but this suggestion could apply there too.

Related:

• Encode/Decode impl for Cow<'_, str> #1343
• Decode impl for Cow<'_, str> #1214

[jplatte]

Instead, I suggest implementing Type, Encode & Decode for:

• T: AsRef<str>
• [T] where T: AsRef<str>
• Vec<T> where T: AsRef<str>

This is not possible. The first impl would conflict with the other two: as far as the trait solver is concerned std may introduce AsRef<str> impls for [T] or Vec<T> (for some T) in the future. Likewise, the two latter impls will conflict with any impls for specific [SomeType] and Vec<SomeType> impls respectively.

[malobre]

I see how the impls for [T], Vec<T> will conflict but T: AsRef<str> and [T] where T: AsRef<str> seems possible ?

Playground

[jplatte]

Right, because the first impl is really for T: Sized and [T] is not Sized. Still this won't really help, the AsRef<str> impl will conflict with almost all other impls since most of the types Encode and Decode are implemented for are Sized.

[malobre]

Got it, sorry for the noise. I'll create another issue for explicit Box<str> impls.

[malobre]

I guess this could be revisited once specialization (rust-lang/rust#31844) is stabilized.