Rain

Yeah, I think the benefits are with longer paths more than anything else, and I'm worried that the branching for shorter paths will reduce perf (will have to see this...

Having thought about this for a bit, I'm quite interested in seeing what this would look like. Could you put up some benchmarks for paths of various sizes and ASCII...

BTW nextest is now available as pre-built binaries, if you're interested in using them: https://nexte.st/book/pre-built-binaries

yeah, I'm thinking that toml-value is just the data model, with an optional serde feature for Serialize and Deserialize support (so not a complete replacement for toml-rs, which also has...

(I'm happy to do this, and also to fix up Windows support.)

Having looked at the impl a bit, I think I'm going to use camino to keep things simple. There's definitely some use cases that may benefit from non-UTF-8 path support,...

Thanks! The main thing `camino` would provide is clearer handling around paths, and proper Windows path handling. For example: * https://docs.rs/vfs/0.5.1/vfs/filesystem/trait.FileSystem.html currently takes `&str` -- it could take `&Utf8Path` instead....

> I feel that something like root.join("foo"). is more ergonomic than root.join(camino::Utf8Path::new("foo")). I also think that if anyone wants to use camino they could either do something like root.join(camino::Utf8Path::new("foo").as_ref()) or...

I also realized that there's a related issue. If `--config` is passed in in this fashion: ``` --config 'k=v' --config foo.toml --config 'k2=v2' --config bar.toml ``` Then the behavior I...

Thanks, that makes sense! If your tests are mostly all in one binary then nextest doesn't have the scope to do much better than cargo test. (Of course, you might...