Stream: project-error-handling

Topic: Philosophy of `From` [split from Meeting 2021-04-12]


view this post on Zulip Jane Lusby (Apr 12 2021 at 19:54):

T implementing TryFrom for an option of itself seems unusual to me

view this post on Zulip Jane Lusby (Apr 12 2021 at 19:55):

but I guess the inner type doesn't need to be T

view this post on Zulip scottmcm (Apr 12 2021 at 20:02):

I don't really have a concrete "oh yes I needed it here". Mostly it's related to my general philosophy that if something's From in one direction should probably be TryFrom (perhaps From) in the other direction. (And if that's not possible, maybe From wasn't a good idea in the first place.)

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:03):

I see

view this post on Zulip scottmcm (Apr 12 2021 at 20:07):

Like .try_into().unwrap() to pull a variant out of a net::IpAddr feels reasonable to me -- it's like a downcast in that it's probably not something you should be doing super often, but...

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:08):

ah, yea that one makes sense to me

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:08):

it doesn't feel like a fundamental property to me though

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:08):

like, I can see constructing something with From as vaguely destructive to the original input

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:09):

or I guess, potentially destructive

view this post on Zulip scottmcm (Apr 12 2021 at 20:11):

Yeah, I agree it's not impossible -- BinaryHeap<T>: From<Vec<T>> is an existing example. But at the same time that's one of those that feels like it needs a comment because it's not obvious what it's doing, and thus maybe it should have been .heapify() or something instead of .into().

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:11):

ah yea

view this post on Zulip scottmcm (Apr 12 2021 at 20:12):

And in general, there's often multiple reasonable destructive ways to convert something, which pushes it away from From.

But regardless, I look forward to checking in try_trait_v2 and being able to deprecate NoneError and force the conversation to stop :upside_down:

view this post on Zulip bstrie (Apr 12 2021 at 20:12):

feels similar to https://github.com/rust-lang/rust/pull/84111 , where impl From<[(K, V); N]> for HashMap loses both the order of the input and any duplicates

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:12):

I wonder if there are any good writeups on when it is and isn't appropriate to use From

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:13):

I definitely have seen a few different approaches

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:13):

specifically, when to use from vs making a constructor method

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:13):

and managing the boundary between constructors as a trait bound you can rely upon

view this post on Zulip Mario Carneiro (Apr 12 2021 at 20:14):

I always struggle with T::new() vs T::default()

view this post on Zulip scottmcm (Apr 12 2021 at 20:14):

My "A: From<B> probably only is good if B: TryFrom<A> makes sense too" heuristic came out of conversations in https://github.com/rust-lang/rfcs/pull/2484

view this post on Zulip Jane Lusby (Apr 12 2021 at 20:15):

I'll definitely be keeping that heuristic in mind going forward to see how well it applies to my experiences

view this post on Zulip DPC (Apr 13 2021 at 13:23):

I generally use From<..> for "equal-ish" types. As in, if I have a struct with a member and i'm creating the struct from that member, I would use from_x as a method instead of the From trait


Last updated: Jan 26 2022 at 14:02 UTC