Human has trouble parsing type in Error message

1

Rust has no trouble parsing, but as I'm only human I have trouble parsing the following error message:

= note: required because of the requirements on the impl of futures::Future for futures::MapErr<futures::AndThen<tokio_tungstenite::AcceptAsync<tokio::net::TcpStream, tokio_tungstenite::tungstenite::handshake::server::NoCallback>, server::connection::Connection<std::sync::Arc<std::sync::RwLock<T>>, tokio_tungstenite::WebSocketStream<tokio::net::TcpStream>>, [closure@redacted>, [closure@redacted]>

Would it be great if the types were more readable instead of manually having to unnpack them in a text editor to figure out what they are?

Below are a few mockups of how the above type could look. I'd like to poll and see which formatting people prefer.

  • I'm fine parsing rust error types, hook me up to std::in
  • Rainbow coloring of nested types
  • Graduated shading of nested types (in hues of blue?)
  • Format types nicely like {:#?} does but for types.
  • Time for something completely different (comment below)

0 voters

Rainbow and nested blue might look something like this:

04
041176×444 94.6 KB

Formatting of the type in a {:#?} style might look something like this:

= note: required because of the requirements on the impl of `futures::Future` for `futures::MapErr<
        futures::AndThen<
            futures::future::FromErr<
                tokio_tungstenite::AcceptAsync<
                    tokio::net::TcpStream,
                    tokio_tungstenite::tungstenite::handshake::server::NoCallback>,
                tokio_tungstenite::tungstenite::Error>,
            server::connection::Connection<
                std::sync::Arc<
                    std::sync::RwLock<T>>,
                tokio_tungstenite::WebSocketStream<tokio::net::TcpStream>>,
            [closure@redacted]>,
       [closure@redacted]>`

I'm sure other languages would have just said it's good enough already, and maybe that's true, but is it the best we can do? Rust loves types, so being able to visualise complex types well is important. I'm really keen to hear other suggestions (however wierd and wacky) of what we could do to make complex types more readable.

5 Likes
2

Yes this is a pain.

Instead of those message though, I suggest we should allow compiler option to choose a brief type names as usually only the (offending) outmost types are relevent. This option should be by default and a "verbose" option to format them like whay you said.

Idealy, the report system shall be able to "hightlight" at least the first "offending" parts, and elipses irelevelent contents. This requires some effect but I think it is worth.

2 Likes
3

If by brief type name you mean MyStruct in crate::module::sub::MyStruct, I'm happy with that. Alternatively maybe the sub::MyStruct part may give better context, though I'd have to see how true that is in practice.

1 Like
4

I'd like all irrelevant parameters to be replaced with _.

If Future is implemented for any T in Foo<T>, then don't display Future for Foo<ActualComplexType>, but Future for Foo<_> instead. Hopefully that applied recursively would cut some of the leaves from that gnarly type tree.

9 Likes
5

Tricky one, I know sometimes having explicit namespaces is really helpful.
We could grey out the namespaces, to me that seems an improvment:

05
051158×198 43.5 KB

To my eye''s its a little easier to parse, but still the structure could be clearer.
I do like the idea of eliding a type (using '_') if we know it's not relevant, but I suspect that would be a lot of work to implement in the compiler.

3 Likes
6

I'm from a field where counting brackets is just a fact of life, so I probably have a fairly strong bias towards it being fine for that reason, but it's worth mentioning that it isn't something that needs to change in the compiler itself.

If it's not already possible as a compiler plugin (which it looks like it may not be after a quick poke around the documentation), it may be worth asking for an injection point to make it possible to format the output a bit better without forcing a global change.

1 Like