Utilities

[hydroper]

You know that the Rust std can't cover all use-cases, even for some simple things, because Rust is a systems language for different purposes. You could end up (in the future maybe) having to add common dependencies to your Bevy project's Cargo.toml manifest, such as regex, lazy_regex, lazy_static, num_bigint...

I think the following obvious things are lacking to prelude or utils.

The only reason I see for not including some crates is only if the dependency version is a problem (inclusively if it's still beta) and the developer would like to specify the dependency theirselves.

If the community agrees with this and no one wants to waste time adding it manually, I can try putting it inside.

Futures

• exec_future(): executes future in the background.
• future_race(): similiar to futures::future::select, but yields just (v, i) instead of (v, i, remaining futures) for simplicity.

Collection literals

Macros for initializing collections (maps and maybe sets).

A way to go

Lazy Statics

lazy_static

Regular Expressions

Alias the regex and lazy_regex crates, which provides literal-like macros too. I just wanted regex and lazy_regex mixed into one.

A way to go

Number

Alias big integer and add comma separation.

A way to go.

You could also re-export num_traits::Signed as it defines is_negative for BigInt.

Serialization

Alias serde and at least serde_json.

A way to go

Etc

etc. (P.S..: I'm not using this)

[MrGVSV]

The reason Bevy doesn't expose a lot of these (afaik) is because it makes the engine a lot more opinionated. It also doesn't offer much. We don't want to force users into using crates they don't need (and the engine itself doesn't use). For example, a lot of people use serde, but the format used varies quite a lot— serde_json would only capture a fraction of users.

So if we did this, we would probably need to put these dependencies behind a feature flag. And we probably don't want them to be the default (since, again, a lot of people might not need them). But if we put it behind a non-default feature flag, then the user has to opt into them, which is effectively as much work as just adding the dependency manually.

Also, I think re-exporting lazy_static would promote an anti-pattern of storing data in statics instead of Resource types. So if we did do something like this, I don't think we'd want to include that particular crate.