Add a "Path()" class to validate the path used inside the project folder.

[hydescarf]

Basically, add a type, or class, or global function that can check if the input String is an accurate path inside the project folder.

# suggestion ways of using it:
var path:Path = "res://folder/file.gd"
var path:Path = path("res://folder/file.gd")
var path:String = path("res://folder/file.gd")

#  extra thought at the bottom of the post
var path = res("folder/file.gd")

Path will have the most functions from String that specially used for path, OR they can just check the value, and then return the value as String. They will also show code completion hint just like how load()/preload() does for project files path.

The benefits I can think of if this is implemented:

• Validate accurate path immediately during coding.
  • String doesn't show the path hint from code completion or errors for wrong path.
  • load()/preload() only shows the path list once, and doesn't do the checking afterwards.
• Immediately crash when debugging if path doesn't exist, as Engine doesn't have to wait until certain function that calls for load("string_unchecked") that doesn't trigger an error during coding.
• @export_path or similar can be introduced, which can resolve some of the exported PackedScene issues.
  • There's no cyclic reference issue as it's just a String. (Although user will still not be able to get written data from that path)
  • @export_path can automatically update when file is renamed or moved (but not deleted). String doesn't because it accounts for general String value, but Path only does for file path in the system.
• Overall, reduce magic string issue.

Extra thoughts:
Do we need siblings res() and user_path()?
We could also use res() as the main name, so that we can skip the res:// when using it, e.g. res("folder/file.gd"). That being said, using path() would be consistent, and user can easily replace the function with load()/preload() and vice versa.

However, only res:// is possible to be validated, user:// and absolute path aren't supported, as they might introduce user issues. And in that case, a better name might be needed instead of Path.

On the other hand, there might be a reason why load()/preload() doesn't do validation on the inserted value. And the reason may be crucial to the proposal.
I'd think that the engine can have a special case to push an error for load()/preload() functions to validate path (not sure if it'd work with external editors), otherwise, this proposal would require a new type Path to handle the error validation.

I believe a path validation is possible, as I did with my own custom script editor plugin, but not sure if doing that to the core engine is an OK thing or not.

Edited: I realized a critical issue with this proposal, as user can combine String and variable e.g. var path = path("folder/" + file_name). Either we find a way to circumvent, or we reduce down to @export_path that doesn't involve combination of values.

[Mickeon]

I think overall, the suggestion feels overly-engineered, as most languages, APIs, or similar make no distinction. But, I do find a Path Variant type interesting... if NodePath didn't exist...

[hydescarf]

I wouldn't disagree with that, it is indeed a too-specific thing that might be only available to the editor.
I also think a FilePath variant type would be helpful to distinct from String type, but that's also just very pin point additions.

Apart from that, there's thought for ResPath (or ResourcePath) which would be specific to the project files for this proposal, and is up to debate.

[KSqrd]

I would argue that while not typical for general language libraries, it's pretty common for game engines. Unreal has a way for me to create an weak object reference that works very similar to this Path proposal. It verifies that the resource exists but doesn't result in pre-loading or any other runtime costs beyond the check. The main advantage, besides validation, is that I can just drag-and-drop resources in the editor into a field of this type. So instead of the right click -> copy path -> paste into string variable flow, a designer can just drag a resource over, which is generally more discoverable and intuitive. You'd also be able to hook up auto-complete when typing names, etc. Obviously, these features go beyond the basic proposal for the Path class, but that still gives you a starting point for all of these engine improvements down the line.

[theraot]

I like the idea, I don't know if it can be implemented fully right now, so it might be for the next major version (in particular if this a new type, which would be used from resource loading to inspector integration, making it a huge change).

So, for our current version of Godot, I like the idea of path expression/function that takes a string and returns an string, but Godot validates that the input string is a path during parsing. So no new type or class is added.

Also, I believe it is possible (albeit more tricky) to have Godot could emit an actual check (with runtime error) if it is not possible to validate during parsing, and emit nothing if the validation happens entirely during parsing.

I know it is not the same as an actual type: mainly you won't be able to specify that a variable must be a path (e.g. a method cannot have a parameter typed as a path), but at least the path expression would ease validation for defensive programming. - Perhaps we can alleviate it with annotations for the method parameters?

[hydescarf]

I'm good with Path not being a variant type, the sole purpose is to emit error for incorrect path, so the function path() alone is fine.

After a few thoughts and tests, apparently, preload() actually emits an error in the editor if the path doesn't exist, but not for load().
The error appears the same at pre-ready and post-ready:

var load = preload("rg"+"asd") # Error at (5, 20): Preload file "res://rgasd" does not exist.

We could theoretically copy the function and alter a bit to return a String and name it path(). (Or check_resource_path() for direct understanding, but it's not for dynamic path). And then have the error parser to register the function to validate the path as well. Not sure how it works at the moment, but you get the gist.