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
Writing some_num.try_into()? can be useful, I noted this somewhere and forgot about it, so I don't have a direct usecase.
Most likely macro generated code would need less typing and casting?
Oh right, it could replace try_new, too.
That's actually the point. The ux crate does that as well and it keeps the interface clean. From<UnderlyingType> would replace new then.
Of course this would need deprecation notes or if that's too extreme we can use feature gates here again (I hope not)
The text was updated successfully, but these errors were encountered:
hecatia-elegua
changed the title
Should we have TryFrom<UnderlyingType>?From<UnderlyingType> and TryFrom<UnderlyingType>May 17, 2023
TryFrom can be used generically, which is a different thing.
Another argument for not providing it would be that users should be nudged in the right direction and since it's not const yet, I agree that we should not provide it unless a usecase crops up.
Edit: less writing for stuff like this maybe:
// generated by macroconstfnset_field3<T:TryInto<u4>>(&mutself,value:T){let field3 = value.try_into().expect("value is not convertible to u4");//...}
lalala.set_field3(6);//maybe 6u8
lalala.set_field3(u2::new(6));
Writing
some_num.try_into()?
can be useful, I noted this somewhere and forgot about it, so I don't have a direct usecase.Most likely macro generated code would need less typing and casting?
Oh right, it could replace
try_new
, too.That's actually the point. The
ux
crate does that as well and it keeps the interface clean.From<UnderlyingType>
would replacenew
then.Of course this would need deprecation notes or if that's too extreme we can use feature gates here again (I hope not)
The text was updated successfully, but these errors were encountered: