Stream: t-lang

Topic: default from impl


Jane Lusby (Apr 24 2020 at 19:20, on Zulip):

How impossible would it be to get impl<T> From<T> for T marked as default?

Jane Lusby (Apr 24 2020 at 19:20, on Zulip):

Screenshot-from-2020-04-24-12-18-40.png Screenshot-from-2020-04-24-12-18-26.png

Josh Triplett (Apr 24 2020 at 19:22, on Zulip):

Huh.

Josh Triplett (Apr 24 2020 at 19:22, on Zulip):

So, two things...

Josh Triplett (Apr 24 2020 at 19:23, on Zulip):

For the actual question, I think the folks who worked on min_specialization might be good folks to ask, as might @nikomatsakis.

Josh Triplett (Apr 24 2020 at 19:23, on Zulip):

For the use case, though: it seems really unusual to me to have an impl From<T> for T instance that isn't an identity.

Josh Triplett (Apr 24 2020 at 19:23, on Zulip):

Calling .into() on a ReturnTrace would add the current location to the trace?

Jane Lusby (Apr 24 2020 at 19:24, on Zulip):

yea, the idea is that when you do ? on an error that does the same thing as this type (was meant as a proof of concept) you'd get a backtrace of the return points

Josh Triplett (Apr 24 2020 at 19:24, on Zulip):

Ah, I see.

Jane Lusby (Apr 24 2020 at 19:24, on Zulip):

this is probably not the right approach

Josh Triplett (Apr 24 2020 at 19:24, on Zulip):

That makes more sense. And yeah, I don't think you want to change the From impl. I think you'd want to look at the Try impl, perhaps?

Jane Lusby (Apr 24 2020 at 19:24, on Zulip):

like we'd probably want a trait to be the hook for types that want to gather the locations

Josh Triplett (Apr 24 2020 at 19:25, on Zulip):

This also seems like a use case that ought to get fed into discussions of how Try should look. :)

Jane Lusby (Apr 24 2020 at 19:25, on Zulip):

yea, that was my plan for the RFC i intend to write for this

Jane Lusby (Apr 24 2020 at 19:25, on Zulip):

i've already talked to centril about this before

Jane Lusby (Apr 24 2020 at 19:25, on Zulip):

a little

Josh Triplett (Apr 24 2020 at 19:26, on Zulip):

FWIW, the From trick above is impressive, especially in how rapidly it produced a "yeet" reaction in me. ;)

Jane Lusby (Apr 24 2020 at 19:26, on Zulip):

I was just hoping I could abuse specialization and track caller to prototype this

Jane Lusby (Apr 24 2020 at 19:26, on Zulip):

ty ^_^

Josh Triplett (Apr 24 2020 at 19:26, on Zulip):

I think using track_caller is a completely sensible approach.

Josh Triplett (Apr 24 2020 at 19:26, on Zulip):

And what you're trying to do makes perfect sense.

Jane Lusby (Apr 24 2020 at 19:26, on Zulip):

but yea i agree it doesnt really make sense for From<T> -> T to like, modify the type

Josh Triplett (Apr 24 2020 at 19:27, on Zulip):

At a minimum, you could prototype this with a .trackme() function.

Jane Lusby (Apr 24 2020 at 19:27, on Zulip):

yea but then it wouldnt work with ? which is the whole point

Josh Triplett (Apr 24 2020 at 19:27, on Zulip):

Prototype. ;)

Jane Lusby (Apr 24 2020 at 19:27, on Zulip):

lol

Josh Triplett (Apr 24 2020 at 19:27, on Zulip):

But yes, it makes sense to try to hook it into the ? desugar.

Josh Triplett (Apr 24 2020 at 19:28, on Zulip):

As another possibility, also using specialization, you could specialize Try for Result<T, YourErrorType>.

Jane Lusby (Apr 24 2020 at 19:28, on Zulip):

oh shit

Josh Triplett (Apr 24 2020 at 19:29, on Zulip):

To augment YourErrorType with the caller's location.

Jane Lusby (Apr 24 2020 at 19:29, on Zulip):

no wait you cant do that with min_specialization

Jane Lusby (Apr 24 2020 at 19:29, on Zulip):

Ill just make a unit type

Jane Lusby (Apr 24 2020 at 19:29, on Zulip):

this is a good idea

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

naw, still not coherent

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

damnit

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

oh but duh

Josh Triplett (Apr 24 2020 at 19:30, on Zulip):

Another possibility would be MyResult<T> which is a "smart wrapper" around Result<T, MyError> (not just an alias).

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

custom result

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

yea

Jane Lusby (Apr 24 2020 at 19:30, on Zulip):

smart wrapper?

Josh Triplett (Apr 24 2020 at 19:31, on Zulip):

That's starting to get into more difficult to use territory, but it would work.

Josh Triplett (Apr 24 2020 at 19:31, on Zulip):

(Right, because it's a Result but with some additional logic.)

Jane Lusby (Apr 24 2020 at 19:33, on Zulip):

I dont think i need to implement all of the logic of result for the proof of concept

Jane Lusby (Apr 24 2020 at 19:33, on Zulip):

gonna just implement the skeleton of the changes that I would need to make to implement this upstream

Jane Lusby (Apr 24 2020 at 19:42, on Zulip):

BOOM

Jane Lusby (Apr 24 2020 at 19:42, on Zulip):
error-return-trace is 📦 v0.1.0 via 🦀 v1.44.0-nightly took 7m14s
 cargo run --example usage
   Compiling error-return-trace v0.1.0 (/home/jlusby/git/rust/error-return-trace)
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s
     Running `target/debug/examples/usage`
ReturnTrace { frames: [Location { file: "examples/usage.rs", line: 18, col: 42 }, Location { file: "examples/usage.rs", line: 14, col: 16 }] }
Jane Lusby (Apr 24 2020 at 20:15, on Zulip):

https://github.com/rust-lang/rust/issues/42327#issuecomment-619218371

scottmcm (Apr 25 2020 at 00:10, on Zulip):

I think that with the current Try trait one could make this work for a MyResult by looking up the caller location in Try::into_result.

But getting it on the wishlist for try trait v4 (or whatever we're on now) is probably the right thing for now.

Jane Lusby (Apr 25 2020 at 02:32, on Zulip):

:+1: I trust yall to remember this when designing the v4 Try trait and beyond

scottmcm (Apr 25 2020 at 03:35, on Zulip):

@Jane Lusby You can also join the design meeting in a week and a bit, if you're interested: https://github.com/rust-lang/lang-team/#meeting-calendar

scottmcm (Apr 25 2020 at 06:21, on Zulip):

Actually, since I'm apparently the one preparing for that meeting (:fear:) do you have any thoughts on exactly which places you wanted to track the frames? On return Err(foo);? On yeet foo;? On a bubbling ?? When the propagation stops at a try{} block? Etc.

Jane Lusby (Apr 25 2020 at 15:54, on Zulip):

Preferably as much as possible

Jane Lusby (Apr 25 2020 at 15:54, on Zulip):

Yeet and ? Should both do it for sure

Jane Lusby (Apr 25 2020 at 15:54, on Zulip):

I'd really want every function boundary to do it but I don't think that's possible so this is going to have to be one of those best practice things

Jane Lusby (Apr 25 2020 at 15:55, on Zulip):

It kinda sucks that you can lose frames by not explicitly proprogating the errors tho

Jane Lusby (Apr 25 2020 at 15:55, on Zulip):

And I'm also worried about how you'd grab the last frame from where you catch it before reporting

Jane Lusby (Apr 25 2020 at 15:56, on Zulip):

But if you return to main that's a non issue

nikomatsakis (Apr 27 2020 at 14:55, on Zulip):

Jane Lusby said:

It kinda sucks that you can lose frames by not explicitly proprogating the errors tho

this, I might add, is an argument of sorts for using some sort of fn-level sugar -- i.e., if you use Fehler and do

#[throws]
fn foo() -> u32 {
    bar()
}

fn bar() -> Result<u32, Box<dyn Error>> { .. }

you get an error, you have to call with bar()? (and thus you get the propagation).

nikomatsakis (Apr 27 2020 at 14:56, on Zulip):

the other version of this is that it is confusing when the error types don't match, sometimes requiring Ok(bar()?) -- i.e., I tend to write code like that precisely to ensure more uniform handling of errors regardless

Last update: Jun 05 2020 at 21:30UTC