Overhaul equality-checking and type-coercion #10553
Replies: 2 comments 1 reply
-
Moving to discussion, as there is no concrete technical implementation provided.
This is much less true since Godot 4.0's release. Compatibility-breaking changes where no automated upgrade path can be provided are now avoided as much as possible. Anything that makes the type system stricter should be a warning by default. GDScript's warning system allows you to make individual warnings be considered as errors, or disable the warning in question in the project settings.
While this is true to a certain extent, it should be remembered that Godot releases are supported for a limited time only. If you want to get security or platform support updates, you will eventually need to upgrade at some point, particularly for games that get regular updates themselves or are networked in some way. |
Beta Was this translation helpful? Give feedback.
-
I agree with you, Godot core and GDScript do not have a consistent thought-out design regarding "insignificant" details. However, I'm not sure how we could improve the situation.
In addition, all of these options, to varying degrees, make it difficult to reuse code between projects, complicate documentation, tutorials, and user support in community channels. |
Beta Was this translation helpful? Give feedback.
-
The current type system in GDscript is kind of a mess.
It performs implicit type coercion on statically-typed variables, which defeats the purpose of having static typing:
It errors if you try to compare dynamically-typed variables of different types, which defeats the purpose of having dynamic typing:
It has inconsistent type-checking behavior for statically-typed variables:
Various proposals have been made for new features that behave in more expected ways, like
is_same()
and===
. My suggestion: learn from Javascript's mistakes, and don't go down that path.Javascript's typing system is famously bad. Many of these quirks are not things you would ever do in a serious program, but several of them are. I've personally, for example, been tripped up by the fact that
NaN != NaN
, but[NaN].includes(NaN)
. Javascript has both a loose equality==
operator and a strict equality===
operator, but it is nigh-universally considered bad practice to ever use==
. (Unless you're comparing strings, because for some godforsaken reason"foo" !== new String("foo")
, but"foo" == new String("foo")
) It also needs yet more equality checks for things===
can't handle, likeisNaN()
(which is itself famously confusing) andNumber.isNaN()
(which does something slightly different).This sort of thing is bad design. Sure, you can learn the pitfalls and how to avoid them (or just use Typescript), but especially for beginners it can be very frustrating. Since GDscript is specifically aimed to be easy to learn, I think avoiding this sort of mish-mash of inconsistent behavior should be a priority.
Javascript's woes come largely from noticing problems with previous implementations, but not wanting to break existing websites, so they keep adding new things that are similar but subtly different from an existing feature. Godot has two big advantages here:
I'm still pretty new to GDscript, so I don't have strong opinions on exactly how types should work, just that the current system is confusing and error-prone. I would generally suggest that:
is_same()
to solve most of the problems that==
had. This is completely backwards; now instead of typing 2 characters, I have to type 10. (This is pretty much what Javascript did by making everyone use===
instead of==
, but 3 times longer.)variable == thing
is incredibly unintuitive.5/2
is2
rather than2.5
, and B) it's bad practice to check floats for exact equality anyway, since floating point errors could make it differ by a tiny amount. Comparing ints to floats usually shouldn't be happening, so it seems fine to me if there's a slight additional friction to do so, like having to useis_equal_approx()
.is_equal_approx()
available for use with floats, but why does0 == false
result in an error,is_same(0, false) == false
, yetis_equal_approx(0, false) == true
? Nobody could reliably predict that. A function likeis_equal_approx()
should behave exactly like the base equality check, with the only difference being its handling of floats, like it says in the name. (Or just error on inputs that are not numbers.)Beta Was this translation helpful? Give feedback.
All reactions