string: add impl From<&IString> for IString

[cecton]

I just notice that this is possible with String but not with IString:

let x = String::from("foo");
let y = String::from(&x);

let x = IString::Static("foo");
let y = IString::from(&x);

I get this issue while using Yew that could be fixed that way:

error[E0277]: the trait bound `implicit_clone::unsync::IString: From<&implicit_clone::unsync::IString>` is not satisfied
   --> packages/yew/src/html/conversion/into_prop_value.rs:298:28
    |
298 |                 VText::new(self).into()
    |                 ---------- ^^^^ the trait `From<&implicit_clone::unsync::IString>` is not implemented for `implicit_clone::unsync::IString`
    |                 |
    |                 required by a bound introduced by this call

[kirillsemyonkin]

Do other ImplicitClone types suffer from this? Would impl<T: ImplicitClone> From<&T> for T be possible?

[cecton]

@kirillsemyonkin it doesn't seem so:

error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
  --> src/unsync.rs:20:6
   |
20 | impl<T: ImplicitClone> From<&T> for T {}
   |      ^ type parameter `T` must be used as the type parameter for some local type
   |
   = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local
   = note: only traits defined in the current crate can be implemented for a type parameter

[kirillsemyonkin]

@cecton What about other types (IMap, IArray)?

[cecton]

Vec doesn't have this feature. I checked already. (I didn't bother checking HashMap but I assume it's the same).

[kirillsemyonkin]

@cecton Weird that they do not. If they are worried about allocations, they would probably ban impl From<&String> for String too. If they believe cloning String is cheap in that case (probably since u8 is Copy), then surely impl<T> From<&Rc<T>> for Rc<T> should be cheap, but I do not see such impl (and for some reason there is impl<T: Clone> From<&[T]> for Rc<[T]> (not T: Copy)... Weren't they worried about allocations and cloning in my previous sentence?). I believe standard library is just incomplete and it shouldn't be a good reason to block the idea because of that, especially since our allocations are supposed to be much less painful than their more broad cases.

[cecton]

I believe standard library is just incomplete and it shouldn't be a good reason to block the idea because of that

I love the spirit ♥️

In my use-case I did have a need for From<&IString> for IString but not for the IArray. Usually I prefer to go with a "per use case basis" as if: if someone needed this, then it's justified (that doesn't mean it's rightfully justified ofc but it has a reason to be).

But I really don't mind adding it for IArray and IMap. Worst case scenario we revert that before 1.0 because we found out it was bad in some way. Not everything has to be perfect and if it's safe to try, we should probably try.