Twitter | Search | |
David Tolnay
58
Tweets
86
Following
447
Followers
Tweets
David Tolnay 17h
Reply Retweet Like
David Tolnay Feb 1
Where does 14 come from? The dependency graph includes argh, argh_derive, argh_shared, heck, proc-macro2, quote, syn, unicode-segmentation, unicode-xid, which is 9 crates.
Reply Retweet Like
David Tolnay Jan 28
Replying to @slurpsmadrips @ekuber
You are hitting in which the compiler randomly forgets where some tokens come from if they pass through an attribute macro.
Reply Retweet Like
David Tolnay Jan 28
Replying to @slurpsmadrips @ekuber
tracing::instrument is a macro ahead of its time. Rustc's implementation of #[...] macros (not include derive macros, which are fine) is just not there yet.
Reply Retweet Like
David Tolnay Jan 26
Replying to @ekuber @rustlang
Higher kinded would be a lifetime from lifetimes to lifetimes (??). Higher ranked would be a "for any" lifetime.
Reply Retweet Like
David Tolnay Jan 26
Replying to @ekuber @rustlang
I think you are asking about higher *ranked*, not higher *kinded* which are a different thing. Primer:
Reply Retweet Like
David Tolnay retweeted
Benjamin Brittain Jan 7
Migrating our large rust codebase from failure to anyhow/thiserror has been considered a large QoL improvement. I'd recommend investing time into doing the conversion.
Reply Retweet Like
David Tolnay Dec 20
Replying to @NikolaiVazquez @yaahc_
That seems to be almost everyone's instinct but it turns out using Display would be way worse ().
Reply Retweet Like
David Tolnay Dec 17
anyhow::Error prints using the Display impls of the cause chain so there isn't a need for a new derive at each level other than Display, which already exists in the thiserror or displaydoc crates.
Reply Retweet Like
David Tolnay Dec 17
Replying to @yaahc_
FWIW it was never the intention that programs that care how errors are printed would return them from main. See where it talks about "Programs that care about the exact structure of their error messages" and "a \"professional\" version of the program".
Reply Retweet Like
David Tolnay Dec 17
Well think about how 's proposal at the top of thread would be impossible if every layer of your error were incorrectly always printing every lower layer of the error too. There would be no way for a library to iterate the chain and print in the intended order and layout.
Reply Retweet Like
David Tolnay Dec 17
Replying to @yaahc_
Is this better than a loop to print the causes in any order you want, and a downcast to access the span? Why does it need to affect the type of the error? fn print_root_cause_first(err: &anyhow::Error) { for e in err.chain().rev() { print(e, span(e)); } }
Reply Retweet Like
David Tolnay Dec 17
I strongly disagree that it was a mistake, Display would be worse. In order for applications to have control over rendering cause chains, error types are required to *not* print their causes from the Display impl. The right approach is exposing is_termination on Formatter.
Reply Retweet Like
David Tolnay Dec 1
Trust a URL crate by a team of browser experts; trust a Unicode crate by Unicode experts; etc. The standard library is written by a team of Rust experts, but where the problem domain benefits from being written by domain experts, slow/careful updates don't substitute for that.
Reply Retweet Like
David Tolnay Dec 1
Rust standard library maintainer here; I would encourage you not to see the standard library as the solution to these points. If I were picking a url lib, I would trust the one used by a real browser with a billion real users written by browser experts, over the one in std lib.
Reply Retweet Like
David Tolnay Nov 17
Replying to @Sunjay03
OTOH in some codebases cloning is the single biggest pitfall for new devs-- A big perf-sensitive Rust codebase at my work found last week 80% of runtime was avoidable cloning, got 5x faster just by cloning less. One eng wrote an "official guide to avoiding clones" for their team
Reply Retweet Like
David Tolnay Nov 7
Replying to @nikomatsakis
🤔 Maybe the standard library could use some full-time attention (unified core/std, error management, more extensive futures support, ...)
Reply Retweet Like
David Tolnay Nov 2
Replying to @pcwalton
Serde? Which is the first html5ever release you consider production quality? So far there have been 10 breaking releases of html5ever in the time that Serde has been stable, though Serde 0.9 and even earlier would definitely meet some definitions of production quality.
Reply Retweet Like
David Tolnay Nov 2
Replying to @UkonnRa @rustlang
FWIW Rust type checking already doesn't happen at runtime. All type checking, including code generated by proc macros, is at compile time.
Reply Retweet Like
David Tolnay Nov 2
"Rust cannot do type-checking in compile time" definitely does not follow from from macros being syntax transformations. =D I assure you that if your derive(Serialize) data structure with Serde contains fields that are not serializable, the program will not compile.
Reply Retweet Like