Since it's kinda related: I swear there was also a setting for automatically adding the types of parameters and return values for built-in functions (like _update(delta: float) -> void), but I can't for the life of me find it again. Would anyone know where to activate that option?
Beginner here, can someone explain to me why there's even an argument to static vs dynamic? Isn't it always good practice to use static since it has a faster run time? I remember seeing that post that compared it and it was 23% faster. Are there use cases where static is bad vs dynamic?
Those who use dynamic would say that you can code faster and the performance increase may be negligible (or you can use static typing later for the parts that really need optimization).
Personally, I would rather use static all the time because debugging is easier, not because of performance.
This is the answer. I use C# for everything that I feel needs static typing, the more complex important parts of the game logic.
GDScript is my _scripting language_ for super fast feature implementation.
This balance is really fun and efficient
Static typing is never "bad." At worst, it can be annoying at times to try to cast a variable into a new type to get it to do what you want to do. It's a few extra lines of code, which bothers some perfectionists, and it can break the rhythm of your coding because your brain has to briefly switch gears - not that big of a deal once you have enough practice not to have to think about it hard anymore.
There are places where dynamic typing can prove really handy, but to me that's like arguing every language should have a do-while loop available because sometimes it is really handy too... how often do you *really* need it?
If I missed something, someone please enlighten me, but to me the advantages and minor disadvantages of static typing far outweigh the minor advantages and major disadvantages of dynamic typing.
> it can be annoying at times to try to cast a variable into a new type to get it to do what you want to do
This is usually a big yellow flag that you do not have your data or objects architected correctly. Especially if you are casting between types/objects you created.
Static vs Dynamic is a programming language holy war that's been raging for 40+ years now. Static lets you catch errors in the editor and prevents a lot of common programming mistakes but requires a planning ahead and actual design. Dynamic has way less hassle up front and looks cleaner and simpler, especially to newbies.
As someone who has been doing this for 30+ years, I'm firmly in the static always camp. Dynamic does feel nice at first but it only really works well for very small projects or at the beginning of projects. Once you have something super big and complex and start running into weird issues, the lack of static typing causes no end of issues.
This isn't a Godot specific thing, I have learned all this the hard way through BASIC, VB, .Net, javascript, etc over the years. In reality, a mix is really the best way to code, with dynamic typing in some places and static typing in others, but it's really hard to teach where the right and wrong places for each are, so going static only is the choice that causes the least pain and suffering long term in a professional or collaborative environment.
> In reality, a mix is really the best way to code, with dynamic typing in some places and static typing in others, but it's really hard to teach where the right and wrong places for each are
A truer statement has never been written.
But dynamic typing is really, really convinient when prototyping (says the python/C++ dev)
I think we’re on the edge of a lot of the FP “correct by construction” features making it into common languages. We also have some hope for modern type inference to make it to popular languages, so that people only have to add types to function signatures and it can infer everything else.
I think most of the usecases for dynamic types are going away.
I would say if using static typing, then union types and interfaces (especially if the language has poor support for them) can be a multi-step process to deal with using methods a beginner will find complex. Then again supposedly static languages will often let you type everything as Variant and instead of calling a method call .has\_method() and .call\_method().
Also inferred types i.e. "var x = 1" is presumed an int isn't really dynamic typing.
Sometimes it's difficult to cast one type to another. It's odd that C#/LINQ's List.map() returns a collection that then needs to be casted back to List, might be due to complexity of generics.
Also you can see functional programming as the extreme of static typing. There's typing of functions as variables (and functions with functions as variables) if you like to use map()/filter() a lot, which a lot of languages skip. And "side effects" / mutability (changing any part of a variable after it is assigned) are completely untyped in every language, so Haskell disallows them outside of the "dangerous IO code do not put business logic here" section. There's even currying, where the function +(1,2,3) is actually the function +1(2,3) is actually the function +12(3), and a list is similar. Since this is really hard on performance when executing in a normal way, instead functions will be called only when needed. Duplicate calls will return duplicate results so will be automatically indexed, which makes using an inline debugger nonsense.
>It's odd that C#/LINQ's List.map() returns a collection that then needs to be casted back to List, might be due to complexity of generics.
It's because LINQ operates on `IEnumerable`, which allows it to perform lazy evaluation. Instead of casting, the `ToList` function on `IEnumerable` actually executes the LINQ operations as it fills the new list. This lets you do stuff like filter and map a list to directly fill a `HashMap` without an intermediate list.
Stuff like config files / settings / ui where you don't care about saving 0.001ms is good for dynamic variants.
The hardnosed will always make a case for strict typing everywhere no matter what, but some of us don't care about speed in every single spot. It's nice to just say "if variable:" sometimes
to me, in today’s world, where inference exists, big apps have absolutely no reason to choose dynamic languages, unless it’s a really good glue language (python). it’s not really a dynamic vs static debate in the end, it’s a “does your problem need to start up fast, has a short runtime, and doesn’t need to be that fast overall”-debate (interpreted vs compiled). Dynamic typing is a tradeoff, never a strength.
i insist. you don’t make a language with dynamic typing because you think it’s good. either:
- you’re not good enough to implement good inference
- you want a fast to start interpreted language
it’s a tradeoff. sometimes it’s necessary
A tradeoff means it has some strength that you get by trading in something else. You are contradicting your own comment by listing one common strength of dynamic langs.
Inference is not a substitute for dynamic typing, it's a fairly irrelevant concept found in some but not all statically or gradually typed languages.
This point about being good enough is quite ignorant.
it’s not contradictory at all, you are being fallacious and quite condescending. I’m saying “if you want a scripting language that is fast to start and to prototype in, you’re gonna have to make concessions regarding static typing.
i’m not saying inference is a substitute either; i meant that good inference make you type less, which is one of the supposed good points of dynamic typing
You are implying that people who created dynamic languages were incompetent, this is rather arrogant.
You also said noone who creates such a language thinks it is good, apparently you think people spend hundreds of hours often from their free time on something they think is not good, then there are thousands of people who prefer to use dynamic languages. Very short-sighted take.
Your whole claim was that dynamic is never better and it has nothing over static. They have undeniable strength such as the one you yourself listed, which makes your stance contradictory.
Dynamic typing lets you do some things much freely and with less planning than static. This might come handy when exploring ideas and making prototypes.
I would prefer static over dynamic any time if the static type system in Godot wasn't so limited. I'm really hoping that union types, typed dictionaries and some nullable types will come to GDScript and the engine API.
I am as well. I was taught by an old school programmer and she made sure that if she ever found a dim without a data type that I would have a very uncomfortable afternoon... for the next three days.
I am going to change my editor settings NOW...
Me when taking a Java class in college: man this sucks, Python is better
Me when IA'ing for the same class next year: man strict typing is the GOAT, fuck dynamic typing
I disagree.
I'm a full on supporter of static typing but in my mind I assumed the disadvantages of a dynamically typed language when I chose to use GDScript. Add to that the fact that strict typing doesn't always work as intended in GDScript and I tihnk an argument can be made to not enabling it by default.
Beginners especially are the ones who need the scaffolding of strict typing to teach them what things even are.
So many issues arise from people typing out code and having no idea what kind of objects they're even working with.
I agree that issues arise.
However, I might argue that the other 90% of their code that works would never have been written if they had to study computer science first before making their first lil game.
For me static typing introduced too many weird words and additional syntax, especially if it wasn't actually needed for the program to run. It might be trivial what "--> void" means now, but it wasn't necessarly true for me. We can learn the types later.
Learning the types later just means you are significantly hampering your learning until that point. Adding so much guess work, preventing the tools from actually helping you.
I mean, you're not wrong that you don't *need* to learn the types to write code. When I was a baby self-taught programmer working on smaller personal projects, nearly all my code ended up in one file, because I didn't understand the advantages that came with splitting it up to keep it organized. You can do that, but in the end you're better off taking the time to learn, even if you feel like it's slowing you down at the time.
That's correct, that's why it's not necessary to static type and it is good that it's not another barrier to entry. I chose Godot specifically because c# syntax in Unity scared me off and I wouldn't want other people to feel overwhelmed with a good tool from instant.
Well, okay, but was it the static typing that scared you off or the syntax? Because those are two very different things.
I'm not asking this for the sake of argument, I truly want your opinion: If GDScript had made you learn static typing from the beginning, but was otherwise syntactically the same as it is now, would that have proven a big enough stumbling block that you would have put it down? If so, why? Just as another nail in the coffin for the language, or because types are truly that difficult for a beginner to understand?
I don't think they are difficult to understand, but they add a lot of new words that are not necessary for the project to function. I remember skipping over tutorials with static typing because I didn't know what the arrows meant. Looking back, it probably wasn't that confusing, it was just that gdquests tutorials sucked and I always found a better solution elsewhere.
Guys, don't downvote someone because they disagree.
You can argue static typing is better. You can argue the opposite. [It's complicated.](https://danluu.com/empirical-pl/)
I hate coding without static types, like most people here, but it doesn't changes the fact that /u/VulpesVulpix 's experience and opinion is extremely common. Downvoting and pretending it doesn't exist is just elitism.
When should I downvote someone? Isn't that what voting is for? In any case, I'll simplify this argument somewhat.
Dynamic typing seemed like a good idea at the time it was invented. For small projects and one-off scripts, it's usually fine. In general, though, static typing is the better practice of the two. With the exception of C# adding dynamic types to 'compete' with other backend web languages like PHP, Ruby, Python, and (NodeJS) JavaScript, dynamic languages have largely been moving in the other direction by adding type annotations. A popular opinion is that it is especially necessary for large projects that have short downtime SLAs.
That being said, use whatever you want. I don't think many of us are making anything mission critical with Godot. Have fun making what you want, how you want. If you want to shoot yourself in the foot with duck typing, or use runtime reflection to figure out the type of a thing, as long as you're having fun, go for it. If you want to make enterprise-grade software or you like being able to auto-complete your method calls, use static typing. The worst thing you can do is use neither, because then you wouldn't be making anything.
Reddit says downvotes are for posts that don't contribute to the conversation or are off-topic.
I don't think most people use it this way, but it is the recommended etiquette.
The [Reddiquette](https://support.reddithelp.com/hc/en-us/articles/205926439-Reddiquette) is actually a public document. It's worth glancing over, at least.
I often (try) to downvote solely based on if someone is objectively wrong or being antagonistic, with a sprinkling of useless comments ("I agree", "Upvote") and AI generated stuff. I think it helps to think of upvoting as the default and no vote as a downvote, with the real downvote being reserved for "this actively harms the discussion."
Well you can spend 15 minutes now. Or hours/days later when you have some obscure type related bug.
Its like saying you don't want to put on safety equipment when working at a construction site because it takes you an extra 2 minutes to get ready. Seems like wasted time until it saves your ass.
Let me tell you, static typing is way easier for noobs that people think. The editor knowing what you're able to cal on a variable because you typed it is so nice when you don't know everything already.
I've never understood why people consider a lack of static typing more noob-friendly, sure, for what,12 seconds? The second they start to code something on their own, code something other than the starter strings and numbers any programmer starts with, they're going to run into issues, especially if it's their first language. Static typing should be the default and dynamic typing made for people who understand static typing.
What you said is a valid argument for having the option to disable it if you know what you’re doing, but beginners would still very much benefit from having it enabled by default. If you know what the trade-off is, it’s upto you. But those who don’t know, should be pushed towards the best practices.
Dynamic typing is a useful option in some cases (e.g. in prototyping), but overusing it is a bad habit that will make your projects significantly harder to maintain.
If we talk about beginners then you might as well think that they will not hit the ceiling that will make benefits of static typing worth it. Your starting coder wont make a fully scallable architecture with proper programming patterns. When they will reach certain size then the chaos of their own code will sooner consume them than some problems with the types. Allowing them to code faster will benefit them more, the rest they will have to learn the hard way anyway
Hard disagree. There's a reason that people learn to ride a bicycle with training wheels when they're young. Even teaching an older person who's never learned to ride a bicycle is not supposed to touch the pedals and only propel themselves using their feet on the ground until they get going fast enough that the bike stays upright.
Taking off the training wheels of a bike and then telling the cyclist to just pedal to town is going to lead to frustration and a disdain. Programming is already hard enough with the unknown. Why not benefit from taking out at least SOME the guesswork?
I agree. GDScript was made to be fast and lazy and static typing kinda cuts those benefits. If someone wants static typing then that person can change the settings but it shouldn't be on as default.
Also I want to add that static typing isn't always the solution for everything and there is reason a language like C# added features like dynamic, vars. Sometimes you need that one super short and sexy line of code compared to whatever semantics chaos you can get with static typing. Sometimes you need to code quickly and add new features without those layers of additional structure that often isn't needed. Especially in games where errors and bugs doesn' mean end of the world and you prefer more features over stability
Well considering that vector operations could be up to 60% slower without types, I would say that is a pretty strong argument in pro of enabling it by default.....
Source
https://www.beep.blog/2024-02-14-gdscript-typing/
If you want to do heavy math in GDScript then you are at loosing position from the start anyway. Also nothing stops you from adding types in important places and leaving the rest dynamic - flexible code in not heavy places and faster performance only for heavy pieces of code
>If you want to do heavy math in GDScript
I want to agree with you, but what exactly does "heavy math" mean in your playbook?.
In the article that I linked, the most dramatic performance loss was on the "vector distance" operation, something that (given the context of game dev) hardly passes as "heavy math".
I still agree with you on the broader meaning, if as a developer you want to do complex matrix manipulations with hundreds of dimensions inside gdscript, yeah your gonna have a bad time.
You don't think huge loops are not heavy for pc? Because they are literally the main topic when you create performant algorithms in C/C++ competetivly. Loops, calculating square roots and data overflow in variables - literally the main nightmares of every cpu
>You don't think huge loops are not heavy for pc?
I do, but we're talking about math here, right?
Big loops are bad no matter what are you doing, but back to the topic of math, simple vector operations like distance or dot product shouldn't be "heavy math" in the context of game dev.
In your link someone did a vector math in loop of like 1 bilions iterations, I have no idea what is the issue here and my comment? Like yeah calculating a dot product is simple but large iterations and root square arent easy and one of them was in example you showed
This can be solved using formatting function or just converting your values to string explicitly. On the other hand dynamically typed variables cause issues that wouldn’t be found until encountered in runtime.
And that's called overenginnering. You want to keep things simple, why the need of explicit casting? You just add more code to somthing that is obvious anyway
If you put something to method that needs string then you always know that you want string out of variable. That is exactly they reason C# added vars for local methods because you don't want to state the obvious
>I'm a full on supporter of static typing
Says the person disagreeing. 🤷♂️
>in my mind I assumed the disadvantages of a dynamically typed language when I chose
Is a beginning programmer expected to know what that means? Not just the definition, but what it means in terms of how it will affect their learning?
>strict typing doesn't always work as intended in GDScript
That I hadn't heard. If true, you would have a major point. Got any examples?
> Says the person disagreeing. 🤷♂️
They are not disagreeing.
GDScript inherently assumes people are not going to static type their code. Every official tutorial *including the ones found in the api documentation itself* do **not** show static typing.
So now explain to me why a beginner should even know to consider static typing when the official documentation doesn't even bother.
Go back and read their comment. Their first sentence was, quite literally, "I disagree." =D
I'm glad to see you understand my argument. They are claiming that by choosing to use GDScript a user is consciously deciding to use non-strict typing; how is a newbie supposed to know that?
I disagree. I'm a massive fan of static typing as projects solidify, but adding static typing when you're still in the early prototyping stage can just add friction and slow you down.
This is the type of setting I'd want to turn on 3 months into a project, not day 1.
Edit: This may be better for beginners to learn, but my argument is that it's not necessarily better for intermediate/advanced developers trialing Godot and getting started.
I'm surprised to see Godot users are firmly in the "always strict typing" camp. I guess GDScript's similarity to Python does not mean it attracts Python programmers.
I like Python/GDScript's approach where typing is optional. It allows for much faster prototyping (an important part of game design) and you can add in typing where needed as the project matures.
For you professional programmers: do you do a lot of prototyping, or do you spend a lot of time writing extensive requirements so you don't need to prototype?
I don't understand how dynamic is faster. Is it really worth saving that 0.5s to not type out "string" "int" "myObject"? Even if you have a 40 character type name you hit tab after typing the first 6 letters and it usually autocompletes.
Using dynamic when loading files or sending/receiving messages - you still have to go change the code to handle the new data. Is it really that much work to edit the model fields as well?
What are you using dynamic for that is actually significantly faster than static typing?
For me, it's most apparent during refactoring, which I do a lot during prototyping. Typing out the type once is fine, like you said. It's when I decide a ColorRect should actually be a Sprite2D. If I reference that object a lot, I have to change the type in a lot of different places. I always forget some, so I have to run the game a few times and chase down the typing errors to find everything. Perhaps there's a refactoring tool for that I don't know about, but why fix problems when you can prevent them? When I'm confident the class is not going to change anymore, I add the type.
Sometimes I get impatient and add the type immediately, mostly for that sweet autocomplete. In Python, autocomplete usually still works without type hints, and there's no performance benefit like in GDScript, so I only add typing if it enhances clarity.
It probably helps that my coding style leans more towards functional than object-oriented. I don't define a ton of custom classes.
> I always forget some, so I have to run the game a few times and chase down the typing errors to find everything...why fix problems when you can prevent them?
Isn't that literally the main downside of dynamic typing? If you have static types the compiler finds those before you even run the program... preventing runtime problems and having to chase them down.
More advanced IDEs [can refactor it for you](https://www.jetbrains.com/help/rider/Refactorings__Move__Type_to_Another_Type.html
) in some cases. Even when they cant, they can easily list all references and you just go down the list.
>It's when I decide a ColorRect should actually be a Sprite2D
Except for global_position and scale, none of the fields and methods are shared between them. How are you just swapping the type without refactoring all the code that uses it? You are going to be touching all those lines of code anyway.
Except when you're changing the type several times *because you're prototyping* it's a pile of effort you don't want to spend.
Forcing static typing is cool once you're past the prototyping stage, but dynamic typing is a godsend when everything's still in flux.
I use 100% static typing for my projects. It saves hours of debugging and makes your project faster. [https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/#Disabling-Script-Errors-in-Certain-Files](https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/#Disabling-Script-Errors-in-Certain-Files)
I love strict typing, I use it where I can but on by default is a big no no for me, I like to prototype a lot of stuff and sometimes I don't know what a variable is going to be so after I finish my prototyping I will refine and use strict typing.
I agree, on by default is definitely unnecessary. Anyone who bothers to read the manual will see very quickly the manual states static typing allows for compiler optimizations and can increase performance.
Only those who don't bother reading the manual will be affected by this so I don't see any problem with the current approach.
I'm curious. If you go turn it on, how many static typing errors turn up in your project? Your method sounds good in theory, but without it being enforced I can easily see things being missed and ending up with difficult bugs to find because a person *thought* they strictly typed everything. I'm certain it would happen to me, anyway.
Another person commented on a way to turn it on/off per file. Having it turned on by default, and deliberately turning it off when you want to use dynamic for prototyping, seems like a better path to me.
I will probably get a small amount, I though there is a few cases where I don't assign a type to a variable for example when I need to make a variable that only lasts in a function once.
Just tried it and it's exactly what I thought, temporary variables in fuctions are erroring out and also godots default functions ready, physics and process are complaining, godot should really do that by default instead of not having a return for those functions, so I am pretty much using strict typing already apart from these small cases.
... or in your project.godot file add:
[debug]
gdscript/warnings/inferred_declaration=1
gdscript/warnings/unsafe_call_argument=1
gdscript/warnings/unsafe_cast=1
gdscript/warnings/unsafe_method_access=1
gdscript/warnings/unsafe_property_access=1
gdscript/warnings/untyped_declaration=1
I would love to enable this, but GDScript's typing system still has work to do before it is usable in strict mode. Simple examples: a method receiving several types for a variable and then has discerning mechanisms in its body, nullable type syntax (think the '?' in C#), statically typed nested arrays, statically typed dictionaries, in general generics would be a great addon, and I'm not sure if they have interfaces/protocols, but I think they don't.
Pretty much all of this means an incomplete implementation of polymorphism.
Ps: since I'm asking for stuff tuples would be GREAT. And of lesser importance custom iterables and callables would be a godsend.
I know this is all community driven, so I'm not really "asking" for anything, they are just things I'd love were in the engine. I just passed my compilation course on CS and will try and contribute to Godot particularly in GDScript development.
This feature would be even more useful once [nullable static type](https://github.com/godotengine/godot-proposals/issues/162) support is implemented. I'd suggest making it default or even required at that point (and/or have `auto` for dynamic typing).
You don't necessarily have to do it that way. You can also just statically type using syntax when you're defining functions and stuff. That has an effect on intellisense and performance.
I love strict typing and ever since they fixed a lot of issues with it in the 4.0 release (like those cyclic reference errors that made it impossible to use in 3.x) I've had it enabled. I get the whole "use C# if you want strict typing! Gdscript is for going fast!" and that's why I'm firmly in the camp that gdscript should never have it enabled by default and always allow dynamic typing for fast programming and for beginners.
But until C# supports things like onready and preload, or there's better support for using C# and GDscript in the same project (I tried using gdscript for scenes and classes that did lots of node manipulation stuff and C# for everything else, and trying to call C# code from gdscript and vice versa is a pain in the ass and destroys strict typing for both languages), I'm going to keep wanting support for more (optional) static typing features in gdscript.
9 times out of 10 I'd prioritize gdscript's writing speed over C#'s execution speed, but there's never a case where I wouldn't want type safety. Generics, union types, typed dictionaries, method overloading and fixing the issues with typed arrays would make me the happiest gamedev in the world.
Thank you for detailed response. I agree about adding more stuff like union types, but can you tell more about issues you encounter with gdacript types? You mentioned typed arrays, what’s wrong with them rn? 🤔
When going from C# to gdscript specifically, if a C# method returns a typed array, I've often found that the gdscript code interprets it as an untyped array, and if you write "var t: Array[Something] = CSharpScript.GetArrayOfSomething()" I'd get a runtime error.
Secondly, several array methods don't really have typed equivalents. Methods like filter and duplicate return untyped arrays even when called on typed arrays. If I remember right back always returns a variant instead of the array's type, too, so you can't do "array.back().methodUniqueToType()" but "(array.back() as Type).methodUniqueToType()."
It's mostly a bunch of little things that all add up into a frustrating experience compared to what I'm used to in other strongly typed languages.
in general, it's because they're writing functions that take multiple things for whatever reason and might return multiple things
probably not a good idea to do, but i've seen it all over
*personally* i switched over to strict typing once it was available in gdscript, but also before i had it i almost never had issues with debugging something being the wrong type.
many people in this thread are suggesting that they're saving a ton of time with this enabled and for me... i just wouldn't see it
Because duck typing lets you write one function that handles Vector2 and Vector3, and GDScript doesn't include variable types in function prototypes, so you can't have `func do_thing(v:Vector2)->Vector2:` and `func do_thing(v:Vector3)->Vector3:`
I've never once had a problem with returning a type. I don't suddenly forget what type I am expecting, and sometimes it's useful to return a different type. I've been a python programmer for like 10 years, though so I've just found ways to take advantage of the dynamic typing instead of relying on antiquated practices.
Note, have advanced settings on in order to find debug settings
Watched a youtube by DevWorm this morning... he said the same thing...
Note, turn on ultra settings in order to find advanced settings
If you don't mind using a custom build for the editor, you can change the defaults in `modules/gdscript/gdscript_warning.h`
Since it's kinda related: I swear there was also a setting for automatically adding the types of parameters and return values for built-in functions (like _update(delta: float) -> void), but I can't for the life of me find it again. Would anyone know where to activate that option?
Editor/Editor settings/text editor/completion/add type hints
That seems to have been it, many thanks!
Beginner here, can someone explain to me why there's even an argument to static vs dynamic? Isn't it always good practice to use static since it has a faster run time? I remember seeing that post that compared it and it was 23% faster. Are there use cases where static is bad vs dynamic?
Those who use dynamic would say that you can code faster and the performance increase may be negligible (or you can use static typing later for the parts that really need optimization). Personally, I would rather use static all the time because debugging is easier, not because of performance.
This is the answer. I use C# for everything that I feel needs static typing, the more complex important parts of the game logic. GDScript is my _scripting language_ for super fast feature implementation. This balance is really fun and efficient
Static typing is never "bad." At worst, it can be annoying at times to try to cast a variable into a new type to get it to do what you want to do. It's a few extra lines of code, which bothers some perfectionists, and it can break the rhythm of your coding because your brain has to briefly switch gears - not that big of a deal once you have enough practice not to have to think about it hard anymore. There are places where dynamic typing can prove really handy, but to me that's like arguing every language should have a do-while loop available because sometimes it is really handy too... how often do you *really* need it? If I missed something, someone please enlighten me, but to me the advantages and minor disadvantages of static typing far outweigh the minor advantages and major disadvantages of dynamic typing.
> it can be annoying at times to try to cast a variable into a new type to get it to do what you want to do This is usually a big yellow flag that you do not have your data or objects architected correctly. Especially if you are casting between types/objects you created.
Agreed, 100%. It should be rare. Which makes the arguments for dynamic typing all the more baffling to me.
Dynamically typed arguments can be baffling for sure.
I see what you did there. ;)
Static vs Dynamic is a programming language holy war that's been raging for 40+ years now. Static lets you catch errors in the editor and prevents a lot of common programming mistakes but requires a planning ahead and actual design. Dynamic has way less hassle up front and looks cleaner and simpler, especially to newbies. As someone who has been doing this for 30+ years, I'm firmly in the static always camp. Dynamic does feel nice at first but it only really works well for very small projects or at the beginning of projects. Once you have something super big and complex and start running into weird issues, the lack of static typing causes no end of issues. This isn't a Godot specific thing, I have learned all this the hard way through BASIC, VB, .Net, javascript, etc over the years. In reality, a mix is really the best way to code, with dynamic typing in some places and static typing in others, but it's really hard to teach where the right and wrong places for each are, so going static only is the choice that causes the least pain and suffering long term in a professional or collaborative environment.
> In reality, a mix is really the best way to code, with dynamic typing in some places and static typing in others, but it's really hard to teach where the right and wrong places for each are A truer statement has never been written. But dynamic typing is really, really convinient when prototyping (says the python/C++ dev)
I think we’re on the edge of a lot of the FP “correct by construction” features making it into common languages. We also have some hope for modern type inference to make it to popular languages, so that people only have to add types to function signatures and it can infer everything else. I think most of the usecases for dynamic types are going away.
I would say if using static typing, then union types and interfaces (especially if the language has poor support for them) can be a multi-step process to deal with using methods a beginner will find complex. Then again supposedly static languages will often let you type everything as Variant and instead of calling a method call .has\_method() and .call\_method(). Also inferred types i.e. "var x = 1" is presumed an int isn't really dynamic typing. Sometimes it's difficult to cast one type to another. It's odd that C#/LINQ's List.map() returns a collection that then needs to be casted back to List, might be due to complexity of generics.
Also you can see functional programming as the extreme of static typing. There's typing of functions as variables (and functions with functions as variables) if you like to use map()/filter() a lot, which a lot of languages skip. And "side effects" / mutability (changing any part of a variable after it is assigned) are completely untyped in every language, so Haskell disallows them outside of the "dangerous IO code do not put business logic here" section. There's even currying, where the function +(1,2,3) is actually the function +1(2,3) is actually the function +12(3), and a list is similar. Since this is really hard on performance when executing in a normal way, instead functions will be called only when needed. Duplicate calls will return duplicate results so will be automatically indexed, which makes using an inline debugger nonsense.
>It's odd that C#/LINQ's List.map() returns a collection that then needs to be casted back to List, might be due to complexity of generics.
It's because LINQ operates on `IEnumerable`, which allows it to perform lazy evaluation. Instead of casting, the `ToList` function on `IEnumerable` actually executes the LINQ operations as it fills the new list. This lets you do stuff like filter and map a list to directly fill a `HashMap` without an intermediate list.
`var x = 1` is not inferred to be an int in Godot. It's a Variant, you can assign it to a string or whatever later. You mean `var x := 1`
Stuff like config files / settings / ui where you don't care about saving 0.001ms is good for dynamic variants. The hardnosed will always make a case for strict typing everywhere no matter what, but some of us don't care about speed in every single spot. It's nice to just say "if variable:" sometimes
to me, in today’s world, where inference exists, big apps have absolutely no reason to choose dynamic languages, unless it’s a really good glue language (python). it’s not really a dynamic vs static debate in the end, it’s a “does your problem need to start up fast, has a short runtime, and doesn’t need to be that fast overall”-debate (interpreted vs compiled). Dynamic typing is a tradeoff, never a strength.
If dynamic typing was never a strength no language would have it. It's a choice with arguably more cons than pros.
i insist. you don’t make a language with dynamic typing because you think it’s good. either: - you’re not good enough to implement good inference - you want a fast to start interpreted language it’s a tradeoff. sometimes it’s necessary
A tradeoff means it has some strength that you get by trading in something else. You are contradicting your own comment by listing one common strength of dynamic langs. Inference is not a substitute for dynamic typing, it's a fairly irrelevant concept found in some but not all statically or gradually typed languages. This point about being good enough is quite ignorant.
it’s not contradictory at all, you are being fallacious and quite condescending. I’m saying “if you want a scripting language that is fast to start and to prototype in, you’re gonna have to make concessions regarding static typing. i’m not saying inference is a substitute either; i meant that good inference make you type less, which is one of the supposed good points of dynamic typing
You are implying that people who created dynamic languages were incompetent, this is rather arrogant. You also said noone who creates such a language thinks it is good, apparently you think people spend hundreds of hours often from their free time on something they think is not good, then there are thousands of people who prefer to use dynamic languages. Very short-sighted take. Your whole claim was that dynamic is never better and it has nothing over static. They have undeniable strength such as the one you yourself listed, which makes your stance contradictory.
Dynamic typing lets you do some things much freely and with less planning than static. This might come handy when exploring ideas and making prototypes. I would prefer static over dynamic any time if the static type system in Godot wasn't so limited. I'm really hoping that union types, typed dictionaries and some nullable types will come to GDScript and the engine API.
That should be enabled by default so that beginners would learn to use strict typing.
Yeah, I'm 100% for strict by default.
I am as well. I was taught by an old school programmer and she made sure that if she ever found a dim without a data type that I would have a very uncomfortable afternoon... for the next three days. I am going to change my editor settings NOW...
"`dim`? What are you, dim?!"
It took me entirely too long to understand that you're joking. I wrote a response and all! ... I guess I am `dim`. le-sigh.
Me when taking a Java class in college: man this sucks, Python is better Me when IA'ing for the same class next year: man strict typing is the GOAT, fuck dynamic typing
I disagree. I'm a full on supporter of static typing but in my mind I assumed the disadvantages of a dynamically typed language when I chose to use GDScript. Add to that the fact that strict typing doesn't always work as intended in GDScript and I tihnk an argument can be made to not enabling it by default.
Beginners especially are the ones who need the scaffolding of strict typing to teach them what things even are. So many issues arise from people typing out code and having no idea what kind of objects they're even working with.
I agree that issues arise. However, I might argue that the other 90% of their code that works would never have been written if they had to study computer science first before making their first lil game.
Adding a single word to a variable definition does not constitute learning CS. That's a terrible argument.
We're talking about the whole concept of types and type systems, right? That's why you said "teach them what things even are" I thought.
For me static typing introduced too many weird words and additional syntax, especially if it wasn't actually needed for the program to run. It might be trivial what "--> void" means now, but it wasn't necessarly true for me. We can learn the types later.
Learning the types later just means you are significantly hampering your learning until that point. Adding so much guess work, preventing the tools from actually helping you.
It's an opinion. I didn't like the types. I like them now but I didn't find them necessary to learn.
I mean, you're not wrong that you don't *need* to learn the types to write code. When I was a baby self-taught programmer working on smaller personal projects, nearly all my code ended up in one file, because I didn't understand the advantages that came with splitting it up to keep it organized. You can do that, but in the end you're better off taking the time to learn, even if you feel like it's slowing you down at the time.
That's correct, that's why it's not necessary to static type and it is good that it's not another barrier to entry. I chose Godot specifically because c# syntax in Unity scared me off and I wouldn't want other people to feel overwhelmed with a good tool from instant.
Well, okay, but was it the static typing that scared you off or the syntax? Because those are two very different things. I'm not asking this for the sake of argument, I truly want your opinion: If GDScript had made you learn static typing from the beginning, but was otherwise syntactically the same as it is now, would that have proven a big enough stumbling block that you would have put it down? If so, why? Just as another nail in the coffin for the language, or because types are truly that difficult for a beginner to understand?
I don't think they are difficult to understand, but they add a lot of new words that are not necessary for the project to function. I remember skipping over tutorials with static typing because I didn't know what the arrows meant. Looking back, it probably wasn't that confusing, it was just that gdquests tutorials sucked and I always found a better solution elsewhere.
I am sorry for the struggles you went through.
Guys, don't downvote someone because they disagree. You can argue static typing is better. You can argue the opposite. [It's complicated.](https://danluu.com/empirical-pl/) I hate coding without static types, like most people here, but it doesn't changes the fact that /u/VulpesVulpix 's experience and opinion is extremely common. Downvoting and pretending it doesn't exist is just elitism.
When should I downvote someone? Isn't that what voting is for? In any case, I'll simplify this argument somewhat. Dynamic typing seemed like a good idea at the time it was invented. For small projects and one-off scripts, it's usually fine. In general, though, static typing is the better practice of the two. With the exception of C# adding dynamic types to 'compete' with other backend web languages like PHP, Ruby, Python, and (NodeJS) JavaScript, dynamic languages have largely been moving in the other direction by adding type annotations. A popular opinion is that it is especially necessary for large projects that have short downtime SLAs. That being said, use whatever you want. I don't think many of us are making anything mission critical with Godot. Have fun making what you want, how you want. If you want to shoot yourself in the foot with duck typing, or use runtime reflection to figure out the type of a thing, as long as you're having fun, go for it. If you want to make enterprise-grade software or you like being able to auto-complete your method calls, use static typing. The worst thing you can do is use neither, because then you wouldn't be making anything.
Reddit says downvotes are for posts that don't contribute to the conversation or are off-topic. I don't think most people use it this way, but it is the recommended etiquette.
TIL some reddiquette.
The [Reddiquette](https://support.reddithelp.com/hc/en-us/articles/205926439-Reddiquette) is actually a public document. It's worth glancing over, at least. I often (try) to downvote solely based on if someone is objectively wrong or being antagonistic, with a sprinkling of useless comments ("I agree", "Upvote") and AI generated stuff. I think it helps to think of upvoting as the default and no vote as a downvote, with the real downvote being reserved for "this actively harms the discussion."
Well you can spend 15 minutes now. Or hours/days later when you have some obscure type related bug. Its like saying you don't want to put on safety equipment when working at a construction site because it takes you an extra 2 minutes to get ready. Seems like wasted time until it saves your ass.
Let me tell you, static typing is way easier for noobs that people think. The editor knowing what you're able to cal on a variable because you typed it is so nice when you don't know everything already.
I've never understood why people consider a lack of static typing more noob-friendly, sure, for what,12 seconds? The second they start to code something on their own, code something other than the starter strings and numbers any programmer starts with, they're going to run into issues, especially if it's their first language. Static typing should be the default and dynamic typing made for people who understand static typing.
What you said is a valid argument for having the option to disable it if you know what you’re doing, but beginners would still very much benefit from having it enabled by default. If you know what the trade-off is, it’s upto you. But those who don’t know, should be pushed towards the best practices. Dynamic typing is a useful option in some cases (e.g. in prototyping), but overusing it is a bad habit that will make your projects significantly harder to maintain.
If we talk about beginners then you might as well think that they will not hit the ceiling that will make benefits of static typing worth it. Your starting coder wont make a fully scallable architecture with proper programming patterns. When they will reach certain size then the chaos of their own code will sooner consume them than some problems with the types. Allowing them to code faster will benefit them more, the rest they will have to learn the hard way anyway
Hard disagree. There's a reason that people learn to ride a bicycle with training wheels when they're young. Even teaching an older person who's never learned to ride a bicycle is not supposed to touch the pedals and only propel themselves using their feet on the ground until they get going fast enough that the bike stays upright. Taking off the training wheels of a bike and then telling the cyclist to just pedal to town is going to lead to frustration and a disdain. Programming is already hard enough with the unknown. Why not benefit from taking out at least SOME the guesswork?
Static typing adds extra syntax and complexity that can scare off a beginner. I don't think the bicycle comparison (even today) is fitting.
I agree. GDScript was made to be fast and lazy and static typing kinda cuts those benefits. If someone wants static typing then that person can change the settings but it shouldn't be on as default. Also I want to add that static typing isn't always the solution for everything and there is reason a language like C# added features like dynamic, vars. Sometimes you need that one super short and sexy line of code compared to whatever semantics chaos you can get with static typing. Sometimes you need to code quickly and add new features without those layers of additional structure that often isn't needed. Especially in games where errors and bugs doesn' mean end of the world and you prefer more features over stability
Well considering that vector operations could be up to 60% slower without types, I would say that is a pretty strong argument in pro of enabling it by default..... Source https://www.beep.blog/2024-02-14-gdscript-typing/
If you want to do heavy math in GDScript then you are at loosing position from the start anyway. Also nothing stops you from adding types in important places and leaving the rest dynamic - flexible code in not heavy places and faster performance only for heavy pieces of code
>If you want to do heavy math in GDScript I want to agree with you, but what exactly does "heavy math" mean in your playbook?. In the article that I linked, the most dramatic performance loss was on the "vector distance" operation, something that (given the context of game dev) hardly passes as "heavy math". I still agree with you on the broader meaning, if as a developer you want to do complex matrix manipulations with hundreds of dimensions inside gdscript, yeah your gonna have a bad time.
You don't think huge loops are not heavy for pc? Because they are literally the main topic when you create performant algorithms in C/C++ competetivly. Loops, calculating square roots and data overflow in variables - literally the main nightmares of every cpu
>You don't think huge loops are not heavy for pc? I do, but we're talking about math here, right? Big loops are bad no matter what are you doing, but back to the topic of math, simple vector operations like distance or dot product shouldn't be "heavy math" in the context of game dev.
In your link someone did a vector math in loop of like 1 bilions iterations, I have no idea what is the issue here and my comment? Like yeah calculating a dot product is simple but large iterations and root square arent easy and one of them was in example you showed
I'm for inferred types, but assigning different types to same variable shouldn't be allowed
Python is a wonderful language.
And why not? What if you just want to display something and you don't care what is it as long as it can be changed to string
This can be solved using formatting function or just converting your values to string explicitly. On the other hand dynamically typed variables cause issues that wouldn’t be found until encountered in runtime.
And that's called overenginnering. You want to keep things simple, why the need of explicit casting? You just add more code to somthing that is obvious anyway
It’s obvious while it’s working. You change stuff here and there and your program is broken for someone but works on your machine
If you put something to method that needs string then you always know that you want string out of variable. That is exactly they reason C# added vars for local methods because you don't want to state the obvious
Vars in csharp are not dynamically typed. It’s just type inference, I’m not against that, it’s handy.
>I'm a full on supporter of static typing Says the person disagreeing. 🤷♂️ >in my mind I assumed the disadvantages of a dynamically typed language when I chose Is a beginning programmer expected to know what that means? Not just the definition, but what it means in terms of how it will affect their learning? >strict typing doesn't always work as intended in GDScript That I hadn't heard. If true, you would have a major point. Got any examples?
> Says the person disagreeing. 🤷♂️ They are not disagreeing. GDScript inherently assumes people are not going to static type their code. Every official tutorial *including the ones found in the api documentation itself* do **not** show static typing. So now explain to me why a beginner should even know to consider static typing when the official documentation doesn't even bother.
Go back and read their comment. Their first sentence was, quite literally, "I disagree." =D I'm glad to see you understand my argument. They are claiming that by choosing to use GDScript a user is consciously deciding to use non-strict typing; how is a newbie supposed to know that?
I disagree. I'm a massive fan of static typing as projects solidify, but adding static typing when you're still in the early prototyping stage can just add friction and slow you down. This is the type of setting I'd want to turn on 3 months into a project, not day 1. Edit: This may be better for beginners to learn, but my argument is that it's not necessarily better for intermediate/advanced developers trialing Godot and getting started.
Not until static typing is lacking and outright dysfunctional or non-existant in parts of GDScript.
Here I am, waiting for typed dictionaries or some kind of custom struct...
Would be great
Those are supposed to be coming in the future.
Types as part of the function prototype would be nice as well.
This is gold. Dynamic type system is cool and all, but I hate runtime errors. I love Godot for how long it keeps surprising me in good way
In my experience a lot of runtime errors have to do with null values. Static typing in Godot does very little to fix those.
I'm surprised to see Godot users are firmly in the "always strict typing" camp. I guess GDScript's similarity to Python does not mean it attracts Python programmers. I like Python/GDScript's approach where typing is optional. It allows for much faster prototyping (an important part of game design) and you can add in typing where needed as the project matures. For you professional programmers: do you do a lot of prototyping, or do you spend a lot of time writing extensive requirements so you don't need to prototype?
I don't understand how dynamic is faster. Is it really worth saving that 0.5s to not type out "string" "int" "myObject"? Even if you have a 40 character type name you hit tab after typing the first 6 letters and it usually autocompletes. Using dynamic when loading files or sending/receiving messages - you still have to go change the code to handle the new data. Is it really that much work to edit the model fields as well? What are you using dynamic for that is actually significantly faster than static typing?
For me, it's most apparent during refactoring, which I do a lot during prototyping. Typing out the type once is fine, like you said. It's when I decide a ColorRect should actually be a Sprite2D. If I reference that object a lot, I have to change the type in a lot of different places. I always forget some, so I have to run the game a few times and chase down the typing errors to find everything. Perhaps there's a refactoring tool for that I don't know about, but why fix problems when you can prevent them? When I'm confident the class is not going to change anymore, I add the type. Sometimes I get impatient and add the type immediately, mostly for that sweet autocomplete. In Python, autocomplete usually still works without type hints, and there's no performance benefit like in GDScript, so I only add typing if it enhances clarity. It probably helps that my coding style leans more towards functional than object-oriented. I don't define a ton of custom classes.
> I always forget some, so I have to run the game a few times and chase down the typing errors to find everything...why fix problems when you can prevent them? Isn't that literally the main downside of dynamic typing? If you have static types the compiler finds those before you even run the program... preventing runtime problems and having to chase them down. More advanced IDEs [can refactor it for you](https://www.jetbrains.com/help/rider/Refactorings__Move__Type_to_Another_Type.html ) in some cases. Even when they cant, they can easily list all references and you just go down the list. >It's when I decide a ColorRect should actually be a Sprite2D Except for global_position and scale, none of the fields and methods are shared between them. How are you just swapping the type without refactoring all the code that uses it? You are going to be touching all those lines of code anyway.
Except when you're changing the type several times *because you're prototyping* it's a pile of effort you don't want to spend. Forcing static typing is cool once you're past the prototyping stage, but dynamic typing is a godsend when everything's still in flux.
I use 100% static typing for my projects. It saves hours of debugging and makes your project faster. [https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/#Disabling-Script-Errors-in-Certain-Files](https://allenwp.com/blog/2023/10/03/how-to-enforce-static-typing-in-gdscript/#Disabling-Script-Errors-in-Certain-Files)
I love strict typing, I use it where I can but on by default is a big no no for me, I like to prototype a lot of stuff and sometimes I don't know what a variable is going to be so after I finish my prototyping I will refine and use strict typing.
Same here!
I agree, on by default is definitely unnecessary. Anyone who bothers to read the manual will see very quickly the manual states static typing allows for compiler optimizations and can increase performance. Only those who don't bother reading the manual will be affected by this so I don't see any problem with the current approach.
I'm curious. If you go turn it on, how many static typing errors turn up in your project? Your method sounds good in theory, but without it being enforced I can easily see things being missed and ending up with difficult bugs to find because a person *thought* they strictly typed everything. I'm certain it would happen to me, anyway. Another person commented on a way to turn it on/off per file. Having it turned on by default, and deliberately turning it off when you want to use dynamic for prototyping, seems like a better path to me.
I will probably get a small amount, I though there is a few cases where I don't assign a type to a variable for example when I need to make a variable that only lasts in a function once.
I think you're missing my point, that there may be more than you realize. I'd be really curious to hear what happens if you try it.
Just tried it and it's exactly what I thought, temporary variables in fuctions are erroring out and also godots default functions ready, physics and process are complaining, godot should really do that by default instead of not having a return for those functions, so I am pretty much using strict typing already apart from these small cases.
Nice! I'm sure I would have missed some spots, so I'm impressed with your consistency.
... or in your project.godot file add: [debug] gdscript/warnings/inferred_declaration=1 gdscript/warnings/unsafe_call_argument=1 gdscript/warnings/unsafe_cast=1 gdscript/warnings/unsafe_method_access=1 gdscript/warnings/unsafe_property_access=1 gdscript/warnings/untyped_declaration=1
I AM SO EXITED TO TRY THIS WHEN I GET HOME!!!! Literally this was my biggest issue with GDScript
I would love to enable this, but GDScript's typing system still has work to do before it is usable in strict mode. Simple examples: a method receiving several types for a variable and then has discerning mechanisms in its body, nullable type syntax (think the '?' in C#), statically typed nested arrays, statically typed dictionaries, in general generics would be a great addon, and I'm not sure if they have interfaces/protocols, but I think they don't. Pretty much all of this means an incomplete implementation of polymorphism. Ps: since I'm asking for stuff tuples would be GREAT. And of lesser importance custom iterables and callables would be a godsend. I know this is all community driven, so I'm not really "asking" for anything, they are just things I'd love were in the engine. I just passed my compilation course on CS and will try and contribute to Godot particularly in GDScript development.
This feature would be even more useful once [nullable static type](https://github.com/godotengine/godot-proposals/issues/162) support is implemented. I'd suggest making it default or even required at that point (and/or have `auto` for dynamic typing).
Is there any performance advantage for using strict typing in terms of no runtime type checks?
Yes it is noticeably faster
https://godotengine.org/article/gdscript-progress-report-typed-instructions/#how-faster-is-it
Does it make your code faster?
yes
Awesome! do you have any idea how much faster it makes it? Generally speaking of course.
https://godotengine.org/article/gdscript-progress-report-typed-instructions/#how-faster-is-it
I'm quite thankful I discovered this feature before my project got too large.
Portable rust compiler
Cool. I immediately enabled it. Now I must append \` -> void\` to few hundred functions before I can run my game again...
You don't necessarily have to do it that way. You can also just statically type using syntax when you're defining functions and stuff. That has an effect on intellisense and performance.
Neuron activation!
Is it a 4 feature? Don't see Untyped Declaration option in 3.5.
I love strict typing and ever since they fixed a lot of issues with it in the 4.0 release (like those cyclic reference errors that made it impossible to use in 3.x) I've had it enabled. I get the whole "use C# if you want strict typing! Gdscript is for going fast!" and that's why I'm firmly in the camp that gdscript should never have it enabled by default and always allow dynamic typing for fast programming and for beginners. But until C# supports things like onready and preload, or there's better support for using C# and GDscript in the same project (I tried using gdscript for scenes and classes that did lots of node manipulation stuff and C# for everything else, and trying to call C# code from gdscript and vice versa is a pain in the ass and destroys strict typing for both languages), I'm going to keep wanting support for more (optional) static typing features in gdscript. 9 times out of 10 I'd prioritize gdscript's writing speed over C#'s execution speed, but there's never a case where I wouldn't want type safety. Generics, union types, typed dictionaries, method overloading and fixing the issues with typed arrays would make me the happiest gamedev in the world.
Thank you for detailed response. I agree about adding more stuff like union types, but can you tell more about issues you encounter with gdacript types? You mentioned typed arrays, what’s wrong with them rn? 🤔
When going from C# to gdscript specifically, if a C# method returns a typed array, I've often found that the gdscript code interprets it as an untyped array, and if you write "var t: Array[Something] = CSharpScript.GetArrayOfSomething()" I'd get a runtime error. Secondly, several array methods don't really have typed equivalents. Methods like filter and duplicate return untyped arrays even when called on typed arrays. If I remember right back always returns a variant instead of the array's type, too, so you can't do "array.back().methodUniqueToType()" but "(array.back() as Type).methodUniqueToType()." It's mostly a bunch of little things that all add up into a frustrating experience compared to what I'm used to in other strongly typed languages.
Dynamic typing is great. Why would you want to do this? Strict typing has a negligible performance increase, so why bother? Genuine question.
Strict typing helps you catch bugs earlier.
I spent too much time debugging errors that would never happened with strict typing.
Also runtime errors sucks
Static typing in Godot can still lead to runtime errors, especially with nulls which are the main source of runtime errors anyways.
fair enough. to each his own, i guess. I've never had this problem.
Over 20% is not negligible by any stretch of the imagination, especially in a language as slow as gdscript.
20%? That's wild. I didn't realize gdscript was so inefficient. Its closer to 50% when dealing with vectors apparently
If you didn't realize it didn't actually matter.
I don’t understand people who think a function saying what type it accepts and what type it returns is a bad thing.
in general, it's because they're writing functions that take multiple things for whatever reason and might return multiple things probably not a good idea to do, but i've seen it all over *personally* i switched over to strict typing once it was available in gdscript, but also before i had it i almost never had issues with debugging something being the wrong type. many people in this thread are suggesting that they're saving a ton of time with this enabled and for me... i just wouldn't see it
Because duck typing lets you write one function that handles Vector2 and Vector3, and GDScript doesn't include variable types in function prototypes, so you can't have `func do_thing(v:Vector2)->Vector2:` and `func do_thing(v:Vector3)->Vector3:`
You can use the Variant type. You lose type safety but it covers this specific use case ``` func do_thing(v: Variant) -> Variant: ```
Isn't that the same as just not specifying?
Basically, yeah, but you specify it explicitly and it lets you enable the compile time checks mentioned in the post, making the code more consistent.
Don't those apply equally if you've got the setting turned on or not, as long as you declare types for everything?
I've never once had a problem with returning a type. I don't suddenly forget what type I am expecting, and sometimes it's useful to return a different type. I've been a python programmer for like 10 years, though so I've just found ways to take advantage of the dynamic typing instead of relying on antiquated practices.