Zachary Harrold

I've marked this as draft for the moment since it needs some unit tests and a QA pass. Unfortunately it's not as simple as I had hoped to resolve, but...

> I tried an extended example of the previous review I did, it does not work: > Example > > The scenario: > > * One extensionless assetloader for asset...

I believe this is now ready for review. I've refactored the `AssetLoaders` type into its own file. I've chosen to do this since adding unit tests for the `AssetLoader` resolution...

> I tried the example I posted again, and I'm a bit unsure if I'm hitting a problem or intended behaviour. > > Each time I update `my-asset` for the...

> I think my confusion arose because listing which extensions are supported by a loader is very explicit: > > ```rust > &["ron", "foo", "json"] > ``` > > but...

I believe the best solution to his problem, a `const fn`, is blocked by [RFC #911](https://github.com/rust-lang/rust/issues/57241). Once `const` float operations are permitted, I imagine almost the entire `bevy_color` crate could...

So I think this needs a well considered solution beyond just "clamping" like `palette` does. The real problem is we need a [tone mapping](https://en.wikipedia.org/wiki/Tone_mapping) solution. Clamping is a form of...

Hi, I believe the issue here is caused by your two different loaders producing the same asset type `C`. In the extension-less asset PR, asset loader resolution will short-circuit file...

For those working on a solution, the current type-name for that system is: ```rust creator::library::show_library::{{closure}} ``` Using `bevy_utils::get_short_name` in that `panic!` reduces it down to: ```rust show_library::{{closure}} ``` Would that...

Looks like that should be pretty simple (and mostly allocation free): ```rust /// Strips the name of generic information, leaving only the module path and type name. pub fn get_base_name(name:...