Using attribute-from-tuple conversion can be error-prone

[dralley]

Creating an attribute from a (&[u8], &[u8]) performs no transformation (escaping) on the provided value, but creating an attribute from (&str, &str) does.

This feels a bit too implicit. It should probably be treated like BytesText instead, where different methods are provided depending on whether the value has been pre-escaped. https://docs.rs/quick-xml/latest/quick_xml/events/struct.BytesText.html

use quick_xml::events::attributes::Attribute;

fn main() {
    // correct
    println!("{:#?}", Attribute::from(("foo", "Bells & Whistles")));
    println!("{:#?}", Attribute::from(("foo".as_bytes(), "Bells & Whistles".as_bytes())));

    // incorrect
    println!("{:#?}", Attribute::from(("foo", "Bells & Whistles")));
    println!("{:#?}", Attribute::from(("foo".as_bytes(), "Bells & Whistles".as_bytes())));
}

Attribute { key: "foo", value: Owned("Bells & Whistles") }
Attribute { key: "foo", value: Borrowed("Bells & Whistles") }
Attribute { key: "foo", value: Owned("Bells & Whistles") }
Attribute { key: "foo", value: Borrowed("Bells & Whistles") }

[Mingun]

I think, we should leave only From<(&str, &str)> (with current behavior) and replace From<(&[u8], &[u8])> with an explicit new method

[dralley]

That seems reasonable, but do you see a reason not to mirror the BytesText API here?

e.g.

• Attribute::from_escaped_bytes
• Attribute::from_bytes
• Attribute::from_escaped_str
• Attribute::from_str

(I don't love the _plain_ naming, admittedly)

[Mingun]

Yes, I think, we should stick to consistent naming. That methods seems reasonable. I think, that we could leave From<(&str, &str)> anyway because it seems ergonomic

(I don't love the _plain_ naming, admittedly)

Agree