structopt VS wg-allocators

Hope you are aware that structopt is in maintenance mode and is merged into clap as of v3.

As I understood you need to implement a command line argument parser for that you can use clap https://github.com/clap-rs/clap or structopt https://github.com/TeXitoi/structopt.

I feel like discovering moves like this is a weakness in the ecosystem today. You can check out some of our discussion on raising visibility

Something I've been giving thought to is how to help structopt users discover that clap3 is their upgrade path. We've put notices in the structopt repo but cargo upgrade and docs.rs won't say anything. See https://github.com/TeXitoi/structopt/issues/525 for more ideas we're considering.

For myself, I have found serde.rs really useful for undertanding their derives while I've always been frustrated with finding anything in structopt's documentation, so I modeled it more off of serde. This ended up both being in structure and not being in docs.rs. I think it really was the structure that was the frustration point for me but there was interest elsewhere in moving stuff out of docs.rs.

I think it would be nice to have a comparison to clap-derive and/or structopt in the README, as that is what I expect most users would compare this to. The subcommand handling looks especially cumbersome compared to deriving on structs and enums.

However, the one place I'm a little curious to rewrite things is the CLI... every time we have to deal with cobra I long for Rust's structopt.

Have you tried https://github.com/TeXitoi/structopt ?

It is written in Rust using the structopt and swayipc crates. It is published on crates.io. The repository is hosted on GitLab. The repository is mirrored on GitHub.

I use structopt, which itself uses clap.

Tracking issue for Storages, and a TLDR on what it is

I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7

Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.

It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7