-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDScript: writing only "array[i]" doesn't trigger an error #7302
Comments
I'd vote for closing this as a non issue. Here is an example: class Test:
var t = 0 setget test_set, test_get
func test_set(value):
t = 0
func test_get():
t += 1
return t
func test():
return Test.new()
func something():
test() # Valid.
1 # Invalid??
var _test = Test.new() # Valid.
_test.t = 5 # Valid.
_test.t # Invalid?? (-> getter modifies value..)
test().t # Invalid?? (-> getter modifies value, even if it is dropped right afterwards)
""" Multiline "comment", which is actually a string
line 2""" # Invalid??
var comment = """A multiline remark that goes
in a variable
even if it looks ugly""" # Valid. Most times, you don't want the editor shouting at you, just because you didn't assign a value of some expression to something. The reason is that sometimes, getting the value has "useful" side-effects, or you actually mean to drop it. |
The test of fire:
If we had a mechanism for warnings though, that's the kind of thing that might be worth mentioning (just like a C/C++ compiler can warn you about unused return values), but it should not be an error. |
@akien-mga Python was written to also work in interactive mode so it makes sense here, however the way GDScript is used (in files, where you don't care about it) makes this a bit odd (and nothing uses that value) Despite all this, if you still feel it's a non-issue I would indeed like a warning system obvious enough to catch this (like line highlight). Note: C# doesn't allow me to write this. Most script languages support it either because of permissive nature or the fact they actually need to (interactive mode, or the fact it used to be a template language for PHP). |
Try the same in C++ ;) |
I know some other languages have this, but GDScript is a new language tailored for a specific use, right? My mistake was really stupid and won't probably do it again (but I'm human, can't say for sure^^). Still, it would be really nice to have at least a warning. |
Again, if we are doing this shouldn't we also highlight lines such as: func _ready():
get_pos() # <-?? |
This is syntactically a function call, so obviously it's not possible to issue such a warning on it. |
Not really, for example, C++ is not written to be used in interactive mode and still allow such expressions without warnings or errors. It just ultimately evaluates to true or false. |
Well, that's how I interpret it in terms of usage. In Python or PHP it shows a good one. What is the actual usage of allowing that in GDScript? (Same question for c++) Or is it just a side effect of the implementation? I'm nitpicking but so far I see none, in the context of what the language was made for. |
@Zylann Speaking about C++, such expressions can be used to quickly evaluate any object to be boolean. It goes way back in C days, when prorammers test if a non-boolean variable is true by doing simply Also, the semicolon I think it is a key feature not a bug in the language. Although I agree that it should give a warning about such use, that is, if there is code analysis functionality available or debugger warnings can be disabled. Otherwise halting execution for this is a bit too much. And using the example bojidar-bg provided, what if a function that does one thing and returns some value and you decided not to do anything with it, are you supposed to create a temp var just to be discarded afterwards! This could have performance implications by creating and destroying objects, even if we are mostly using references. |
@RebelliousX I was primarily asking about GDScript, and what usage this could have (C++ inherited a lot of features over time). GDScript is higher-level and has no semicolons. I also agree that function calls cannot be checked since they explicitely execute "logic" that can't be assumed to be a get operation. There are properties of course that can trigger a function, but as I said earlier, relying on that to write an unused get is against properties design and bad practice (IMO). A warning would be fine :) |
@Zylann You missed my point, what I meant about the example of the function call that returns a value applies to expressions that don't do anything. In fact, both will look the same in the end when converted in bytecode, the function call is simply a different execution block or stack frame, the original stack frame sees nothing but the returned value, not the logic of the function. I mentioned C++ since you said that your question applies to C++ too. I just gave you an example of an expression which is the empty statement the semicolon. Well this issue doesn't really bother me, I have seen worse that the compiler errors were suppressed when they shouldnt. Leading to hard to debug code because it goes unnoticed. But I dont recall the issue, it escaped my mind. |
I didn't say it applied to C++ (well C++ allows this but other languages don't). An editor warning actually makes sense because if the compiled bytecode doesn't tell the difference, a parser can. It would then fall into these "good practice warnings" that don't prevent the code to run, but are worth mentionning. |
Still reproducible/relevant in 3.1 master 48890b1 : it doesn't trigger error. |
GDScript would benefit in a system for warnings where this kind of things could be reported. |
Closing since this is now a warning. |
Tested on my Godot fork (last update 4d8bed3)
Windows 10 64 bits
I wrote this in GDScript:
I forgot to assign a value to
pts[j]
or do anything with it. However, it didn't trigger any error, the code probably did nothing at all. It took me some time to find this, it would be nice for Godot to indicate this as an error.The text was updated successfully, but these errors were encountered: