Stream: project-error-handling

Topic: Deriving Display


view this post on Zulip Lokathor (Sep 20 2020 at 14:39):

@Jake Goulding Not being able to derive Display isn't a thing for absolutely no good reason at all

view this post on Zulip Jake Goulding (Sep 20 2020 at 14:40):

That seems like a strong opinion you have that isn’t immediately relevant to this topic of enums. Perhaps it would be better elsewhere?

view this post on Zulip Lokathor (Sep 20 2020 at 14:41):

Well if we could drive Display we could also derive Error, was the context there is all. We don't need to elaborate on it too much though.

view this post on Zulip Jake Goulding (Sep 20 2020 at 14:43):

Topics are cheap, creating one is easy.

no worries, I did it for you.

view this post on Zulip DPC (Sep 20 2020 at 14:43):

i was writing a rfc for derivin display in 2019, things happened in life so didn't get about finishing it. Gonna give it a try soon

view this post on Zulip Lokathor (Sep 20 2020 at 14:45):

Actually I think the better long term plan, for errors, is something like jane's Reporter system, in which case the Error trait that goes with that can just drop the Display bound entirely.

view this post on Zulip Jakub Duchniewicz (Sep 20 2020 at 14:47):

I am curious why Display is non-derivable, it is stated that it is so by design because it is user-facing. Is there a specific rule in the language regarding which traits should be derivable and which not?

view this post on Zulip Jake Goulding (Sep 20 2020 at 14:58):

@Jakub Duchniewicz Could you share what the result of deriving Display would be for some representative types?

view this post on Zulip Joshua Nelson (Sep 20 2020 at 15:04):

I would like to derive Display the way thiserror does it, where it's basically the same as a handwritten impl but without boilerplate

view this post on Zulip Joshua Nelson (Sep 20 2020 at 15:05):

so you'd have

#[derive(Display)]
enum Err {
   #[display = "file not found"]
   NotFound
}

or something like that

view this post on Zulip Joshua Nelson (Sep 20 2020 at 15:06):

if it's in std, it might not want to do all the tricky bits with fields (display = "{.0}"), I'd be fine with requiring an explicit impl Display for that

view this post on Zulip DPC (Sep 20 2020 at 15:09):

there was some concerns for Display, as to what it "form" it would choose since it is user facing

view this post on Zulip Jake Goulding (Sep 20 2020 at 15:15):

Do any compiler-provided derives use associated attributes?

the way thiserror does it,

FWIW, SNAFU does something similar:

#[derive(Display)]
enum Err {
   #[snafu(display("file not found {}", foo))]
   NotFound { foo: i32 }
}

We forbid enums without named fields, partially because of the .0 issue.

view this post on Zulip Jane Lusby (Sep 20 2020 at 15:22):

wait, @Lokathor how would using a reporter let us drop the Display bound from the error trait?

view this post on Zulip Jane Lusby (Sep 20 2020 at 15:23):

something like eyre still needs display

view this post on Zulip Jane Lusby (Sep 20 2020 at 15:24):

I do have some ideas about a 3rd fmt trait called Report that could be used to fix some of the reporting inconsistencies at expect/unwrap/Termination

view this post on Zulip Jane Lusby (Sep 20 2020 at 15:24):

but that's also only half baked right now

view this post on Zulip Jane Lusby (Sep 20 2020 at 15:24):

and that plan relies on specialization so it's not gonna happen any time soon

view this post on Zulip Lokathor (Sep 20 2020 at 15:26):

i guess some code somewhere needs to know how to print a problem, and in that sense maybe it needs Display still, but i was initially thinking/hoping that the reporter would be smart enough via (insert magic here) to turn a plain Debug impl of an error into a report.

view this post on Zulip Joshua Nelson (Sep 20 2020 at 15:28):

personally I wouldn't want debug and display to be the same or similar most of the time

view this post on Zulip Joshua Nelson (Sep 20 2020 at 15:29):

except in trivial cases like fn fmt(&self) { self.0.fmt() }

view this post on Zulip DPC (Sep 20 2020 at 15:33):

agreed

view this post on Zulip Lokathor (Sep 20 2020 at 15:43):

That is exactly what I do almost always want out of the impl

view this post on Zulip Jakub Duchniewicz (Sep 20 2020 at 17:20):

Jakub Duchniewicz Could you share what the result of deriving Display would be for some representative types?

My bad, I read up the docs once again and I understand why it is non-derivable now :)
A stray thought(probably already thought over) - can't we check if a given type violates the UTF-8 requirement during compilation, thus informing user that the given type cannot derive Display?

view this post on Zulip Jake Goulding (Sep 20 2020 at 17:25):

Jakub Duchniewicz said:

can't we check if a given type violates the UTF-8 requirement during compilation, thus informing user that the given type cannot derive Display?

I'm not following exactly what you mean by this. UTF-8 is semi-related, but ultimately feels fairly orthogonal to the point.

view this post on Zulip Jakub Duchniewicz (Sep 20 2020 at 17:33):

Jake Goulding said:

I'm not following exactly what you mean by this. UTF-8 is semi-related, but ultimately feels fairly orthogonal to the point.

Maybe I am utterly confused about why we cannot derive Display, but the docs state it is related to UTF-8 representation of the deriving struct's fields.

view this post on Zulip Jake Goulding (Sep 20 2020 at 17:40):

Hmm, those docs are a bit unfortunate. I prefer those on Display itself:

Display is similar to Debug, but Display is for user-facing output, and so cannot be derived.

view this post on Zulip Lokathor (Sep 20 2020 at 17:53):

If the derive would produce inappropriate output for a type, just don't derive in that case.

view this post on Zulip Jubilee (Sep 21 2020 at 09:48):

Mmm, what exactly is it in std::error::Error that requires display formatting...? Is there a reason Debug wouldn't be good enough...? Because the repr is unstable, I guess?

view this post on Zulip Jake Goulding (Sep 21 2020 at 11:18):

No code in Error requires Display. It’s a semantic requirement — errors are generally shown to a human being. Debug is meant to be shown to programmers, not human beings.

view this post on Zulip Jubilee (Sep 21 2020 at 12:39):

rust_humanity.png

view this post on Zulip Jane Lusby (Sep 21 2020 at 13:01):

omg

view this post on Zulip Jane Lusby (Sep 21 2020 at 13:01):

lol

view this post on Zulip Jane Lusby (Sep 21 2020 at 13:02):

yea, I'd say that Display is the interface to an individual error's "error message". Debug almost always ends up being the interface to a description of it's content.

view this post on Zulip Jane Lusby (Sep 21 2020 at 13:03):

if we switched to debug we'd still have to do all the same manual definition except now we'd be competing with the pre existing debug derive


Last updated: Jan 26 2022 at 14:02 UTC