You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the interpreter API, I noticed that Value implements TryInto instead of TryFrom: this has a few drawbacks and the doc suggests to avoid direct implementation. For example while it's possible to do
let v = Value::from(123i32);
let can_do: i32 = v.try_into().expect("Not a i32");
but it is not possible to do
let v = Value::from(123i32);
let cant_do: i32 = i32::try_from(v).expect("Not a i32");
Implementing TryFrom<Value> for $ty will provide a blanket implementation for TryInto<$ty> for Value, while the inverse is not true. This would also allow to implement functions with generic types that can be obtained from a value, like where T: TryFrom<Value> - while AFAICT this is not possible with the current implementation, without using workarounds.
I forked slint with the intent to open a PR, but I stopped before actually opening it because I'm not sure if this choice was intentional or not (I see no reason why to avoid implementing TryFrom instead of TryInto, but you might have some).
Would a PR be welcome to fix this?
The text was updated successfully, but these errors were encountered:
Using the interpreter API, I noticed that
Value
implementsTryInto
instead ofTryFrom
: this has a few drawbacks and the doc suggests to avoid direct implementation. For example while it's possible to dobut it is not possible to do
Implementing
TryFrom<Value> for $ty
will provide a blanket implementation forTryInto<$ty> for Value
, while the inverse is not true. This would also allow to implement functions with generic types that can be obtained from a value, likewhere T: TryFrom<Value>
- while AFAICT this is not possible with the current implementation, without using workarounds.I forked slint with the intent to open a PR, but I stopped before actually opening it because I'm not sure if this choice was intentional or not (I see no reason why to avoid implementing
TryFrom
instead ofTryInto
, but you might have some).Would a PR be welcome to fix this?
The text was updated successfully, but these errors were encountered: