Unexpected non-optional #63
Comments
|
Agreed, this information is sadly not present in Godot. I suspect the only correct thing to do today is to flag both returns and parameters as optional and slowly introduce an annotation system to flag their nullability |
|
this is not a new problem, sadly: |
|
As I ponder this challenge, I think that it would be relatively innocuous to make all arguments optional, from an API usability, it might not be bad, but we would get some exceptions at runtime - just like C# or GDScript would. The return values are a bit more complicated, there are some 545 of those spread across functions and properties. The properties we might be able to write a script to instantiate every object type in Godot, and attempt to set/read the value to null, and those that abort, we can safely flag as non-Optional, the rest we flag as Optional. Maybe a script to track every constructor that initializes 'Ref' fields beyond the default might be useful to determine if nulls are allowed or not. |
|
Update, I did some measurements:
|
|
Ok, I have settled on a plan. The baseline is that all parameters that are object references can be optional, this matches the C# behavior, and will produce runtime errors as opposed to compile time errors for those cases. The same applies for return values. That said, I now have a list of custom return values and parameters that can be manually be extended to flag "This return type is never nil" or "this parameter can never be nil" that we can grow over time. The bad news is that this will likely produce some churn on the code that relies on this, but it is also the right thing to do. |
Godot sadly does not annotate their functions and properties to include information whether they are optional or not. This is an issue that has been raised a long time ago and has gained little to no traction: godotengine/godot-proposals#2241 This poses a problem, because certain Godot APIs would return nil, and I would try to create an object out of it, and crash, while a nil return is ok. It also posed a problem for APIs that could take a nil parameter, but instead, in SwiftGodot, you had to create an instance of the object, even if it is unnecesary or not the desired outcome. So I have now settled on an evolutionary plan: * For now, all reference types that could have been nil either as a parameter or a return value, are declared as swift optionals. * I have introduced a hardcoded list of method return types and method arguments that can be used to flag exceptions to this: scenarios where we can verify that the return value would never be nil, or the parameter demands a non-nil argument. The list currently is hardcoded in Swift, but will eventually move to a Json file to make it easier to work with. Sadly, this means that there will be some churn, until all this is properly validated. This is a fix for this issue: #63 Some additional data: * Some 114 property returns were affected * Some 432 method returns were affected
|
Neat thanks very much. |
Godot sadly does not annotate their functions and properties to include information whether they are optional or not. This is an issue that has been raised a long time ago and has gained little to no traction: godotengine/godot-proposals#2241 This poses a problem, because certain Godot APIs would return nil, and I would try to create an object out of it, and crash, while a nil return is ok. It also posed a problem for APIs that could take a nil parameter, but instead, in SwiftGodot, you had to create an instance of the object, even if it is unnecesary or not the desired outcome. So I have now settled on an evolutionary plan: * For now, all reference types that could have been nil either as a parameter or a return value, are declared as swift optionals. * I have introduced a hardcoded list of method return types and method arguments that can be used to flag exceptions to this: scenarios where we can verify that the return value would never be nil, or the parameter demands a non-nil argument. The list currently is hardcoded in Swift, but will eventually move to a Json file to make it easier to work with. Sadly, this means that there will be some churn, until all this is properly validated. This is a fix for this issue: #63 Some additional data: * Some 114 property returns were affected * Some 432 method returns were affected
I noticed that there are some variables in SwiftGodot which are shown as non optional.
For example GeometryInstance3D.materialOverride. In Godot this is generally nil unless you assign it but it appears as if SwiftGodot assumes it's populated? In the code of GeometryInstance3D it appears to be force unwrapping it instead of just making it an optional value. I kind of think this might crash if you ever check it when there is no value present.
There are numerous things that are optional in Godot and don't have an default value and should just be nil.
This also works for
MeshInstance3D. getSurfaceOverrideMaterial()or evenMeshInstance3D.meshThe text was updated successfully, but these errors were encountered: