Remove or shrink bevy_utils

[doonv]

What problem does this solve or what need does it fill?

bevy_utils is a collection of unrelated utilities for Bevy. Utility modules/classes/libraries are generally frowned upon in the programming community since they are most likely a sign of poor organization.

What solution would you like?

Move bevy_utils's contents into existing bevy crates or into separate crates.

Long list of what to do with each item in bevy_utils

• BoxedFuture could probably be removed since async in traits were added in Rust 1.75
• all HashMap related stuff: no idea where to put that.
• Move EntityHash related types into bevy_ecs #11498
• OnDrop could be its own crate
• tracing related stuff: put in bevy_log
• once related stuff: I would put it in bevy_log, but this could cause some issues (see move once from bevy_log to bevy_utils, to allow for it's use in bevy_ecs #11419)
• get_short_name: put in bevy_reflect
• SyncCell: use std::sync::Exclusive when stabilized (Tracking Issue for Exclusive rust-lang/rust#98407)
• SyncUnsafeCell: use std::cell::SyncUnsafeCell when stablized (Tracking Issue for SyncUnsafeCell rust-lang/rust#95439)
• generate_composite_uuid: Maybe contribute this to the uuid crate?
• label module: Sounds like a bevy_reflect thing but isn't actually used anywhere there so idk
• Interned: put in bevy_ecs
• futures module: only used in bevy_render, so put it there.
• FloatOrd: could be its own crate
• default: Could be its own crate (The default crate already exists, so maybe we should use that)
• CowArc: Could be its own crate

[alice-i-cecile]

Yes please: I want this crate eliminated!

[alice-i-cecile]

I think we may want to spin up new crates in the Bevy org for some of the stand-alone utilities.

@cart, would that make sense to you? Things like the default function crate would be good to split out, and will change slowly enough that I don't have concerns about moving it out of the monorepo.

That said, I know you're reluctant about increasing crate number, just because it's a popular misguided punching bag for "dependency bloat".

[doonv]

I'm curious whats the compile-time performance penalty of switching between compiling different crates vs. the compile-time performance penalty of compiling unused parts of a crate.

[hymm]

label is used in bevy_ecs to define ScheduleLabel trait and SystemSet trait. So maybe should be there.

get_short_name is used in bevy_asset in a Debug impl, bevy_ecs for some ambiguity reporting, and bevy_heirarchy for a warning. So I don't think it makes sense in bevy_reflect which is an optional dependency for those crates. Not sure where it should go though.

[alice-i-cecile]

get_short_name feels like a general purpose Rust utility, or maybe something that belongs in bevy_reflect for working with types and paths.