Accept `&AssetPath` instead of `&str` in `AssetPath::resolve`

[Shatur]

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

AssetPath::resolve and AssetPath::resolve_embed accept &str and parse it internaly. But if you already have AssetPath, it's wasteful to call .to_string and let resolve parse it again:

bevy/crates/bevy_asset/src/path.rs

Lines 424 to 428 in 8813c18

	if let Some(label) = path.strip_prefix('#') {
	// It's a label only
	Ok(self.clone_owned().with_label(label.to_owned()))
	} else {
	let (source, rpath, rlabel) = AssetPath::parse_internal(path)?;

What solution would you like?

Accept &AssetPath instead of &str in AssetPath::resolve looks like a better API to me.

What alternative(s) have you considered?

Add _str suffix to the current methods and and new methods that accept &AcceptPath.

[Eyad3skr]

Hi! I’d like to work on this if it’s still available.

My current plan after I checked out the issue (very open to feedback) is to:

1. inspect existing AssetPath::resolve / resolve_embed call sites to confirm the stringify -> re-parse pattern,

2. add unit tests to lock in current behavior,

3. then explore an API that allows resolving from an existing AssetPath to avoid unnecessary parsing, while keeping existing behavior unchanged.

Before implementing anything, I wanted to check whether this general direction makes sense, and whether you’d prefer a specific API shape (e.g. additional methods vs. a small trait to abstract over &str and &AssetPath).

This would be my first contribution to Bevy, so I’ll keep the change scoped and follow existing conventions. I would love to hear a feedback soon. Thanks!

[Shatur]

The plan sounds good!

I think a multiple methods would be better.

[Eyad3skr]

Sounds good, I’ll proceed with adding additional methods that accept &AssetPath, keeping the existing &str APIs unchanged.

Small note: I’m currently in the middle of finals, so it may take a bit of time, but I’m planning to work on this and hopefully have progress within the coming week.