Open Gnumaru opened 4 months ago
See also:
This other proposal is similar yet different.
My whole point is to have the editor to yield gdscript parser errors whenever a string literal for an nonexistent resource path is used. It does not seem feasible or even desirable to do this for any kind of string literal, so I proposed a special prefixed string literal similar to the raw string.
With this we could not only refer do directories instead of files, but also refer to non importable files, like for example a xlsx file that get's exported as-is along with the project. Even for edit time only usage, we can refer inside tool scripts to files and folders that only exist at "edit time" so that the tool scrips can do certain automation using these files.
This other proposal is similar yet different.
Hence why I didn't close this as a duplicate
But also consider using UID paths to retain stability
I think this is too specific a thing to add to the language. If we do decide to add something similar, I would prefer it to be a function-like keyword, since there is preload()
. Let's say respath(path: String) -> String
, which works as you described, but also supports constant expressions like respath(MY_DIR + "/file.txt")
.
A more general approach was to add compile-time functions to the language so that you could implement it yourself. But this is a difficult task that is not planned at the moment.
Another approach is to create an EditorScript
that will scan project files and warn about invalid paths:
A project refactoring can easily break a lot of things since the now invalid resource path string literals will lead to runtime errors instead or parse time errors and may only be noticed a lot of time after the refactoring.
This can be easily avoided by doing search and replace for the file you just moved.
Describe the project you are working on
more than one godot project
Describe the problem or limitation you are having in your project
String literals for resource paths in gdscript are error prone. A project refactoring can easily break a lot of things since the now invalid resource path string literals will lead to runtime errors instead or parse time errors and may only be noticed a lot of time after the refactoring. The preload function issues a parser error while trying to preload an inexistent resource path, but not the load function and neither FileAccess.open or any other function dealing with file/dir paths which may be resource paths.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Create a new string literal similar to the raw string literal, preceded by 'respath' (or, if it really needs to be a single character, 'p') which does in parse time the exact same validation that already happen on preload. This way the same safety that preload has can be used in any other place, like in load or in FileAccess.open
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
using a string delimiter preceded by respath
or res to be shorter
or even p if we need it to be a single character
The parser will, at parse time, check for the existence of that path (regardless if is a directory or file). If the path does exist, the parse will be successful. If the path does not exist, it will issue a parser error identical to the one that already exists in the preload function
If this enhancement will not be used often, can it be worked around with a few lines of script?
This is a gdscript parser feature. The easiest way to work around it is to use a tool or external script to procedurally generate a fake enum (a named class with a bunch of string constants) with one entry for every dir/file path in the project, and never again use string literals, just the constants in the enum. This way any project refactoring (as long as followed by the regeneration of the enum) will lead to compilation errors due to scripts using inexistent constants in the enum
Is there a reason why this should be core and not an add-on in the asset library?
gdscript itself is part of core and no changes to the parser can be made an add-on.