html!: Remove the special for syntax when rendering iterators

[jstarry]

Problem

It's not intuitive to use a special syntax for rendering iterators, especially when that syntax uses a rust keyword 😝

Proposed

Implement Into<VNode> for IntoIterator<Into<VNode>>

Before

html! {
   for self.props.items.iter().map(renderItem)
}

After

html! {
   self.props.items.iter().map(renderItem)
}

[hgzimmerman]

I've attempted to get started with this, but I'm encountering conflicting implementation errors with the T: ToString impl.

The following code:

impl<COMP, T, U> From<T> for VNode<COMP>
where
    COMP: Component,
    T: IntoIterator<Item = U>,
    U: Into<VNode<COMP>>
{
    fn from(_: T) -> Self {
        unimplemented!()
    }
}

produces the error:

error[E0119]: conflicting implementations of trait `std::convert::From<_>` for type `virtual_dom::vnode::VNode<_>`:
   --> src/virtual_dom/vnode.rs:111:1
    |
98  |   impl<COMP: Component, T: ToString> From<T> for VNode<COMP> {
    |   ---------------------------------------------------------- first implementation here
...
111 | / impl<COMP, T, U> From<T> for VNode<COMP>
112 | | where
113 | |     COMP: Component,
114 | |     T: IntoIterator<Item = U>,
...   |
119 | |     }
120 | | }
    | |_^ conflicting implementation for `virtual_dom::vnode::VNode<_>`

Without the ability to specify negative traits or use trait specialization, I don't see an immediate way forward without modifying other code.

Would removing the T: ToString impl and replacing it with concrete implementations for String, &str, Cow<&str> [1] be an acceptable way forward?

[1] https://doc.rust-lang.org/alloc/string/trait.ToString.html#implementors

---

Edit:
Its harder than I thought.
I get another error if i just impl From<String> for VNode<COMP> on the basis that
upstream crates may add new impl of trait `std::iter::Iterator` for type `std::string::String` in future versions

[jstarry]

From #622

I don't see the ideal case being possible without trait specialization or mutually exclusive traits landing first, which I'm guessing would take a year at the earliest.

Closing due to Rust limitation