i propose that assigning returns assigned value, so we can write like:
var_one = var_two = 'some value'
and even
while some_var = some_func() != null:
Note that this has the (IMO) bad side-effect of allowing this without a syntax error:
if a = b:
print("They are... equal! yay")
(Ah and BTW, nice to see new simple design discussion issues about GDScript, they would make the language a bit easier to use IMO)
gdscript converts other types to bool by default?
nevertheless this syntax is common for most languages and even for beloved C# :smile:
exactly for this situation there is inverse syntax:
if 1=a:
Well, yeah, everything can be converted to bool or string :smiley:
I know this is typical syntax, but, I guess even this is better, and way harder to make mistakes with:
if var matches = JS.String.match.call("65", JS.util.regex("\\d+")):
print(matches)
Also, note that with the proposed syntax, this will not really work: :wink:
extends GDScript
var a = b = 5 # Error, no variable b found OR expected a constant expression
no i do not mean to declare vars like this (but would be cool too)
because i use
var a; var b
to declare multiple variables. but if we can declare and assign multiples it would be even better :grin:
The parenthesis could be also used :
~while (some_var = some_func() != null):~
while (some_var = some_func()) != null:
if (a = b): print("They are... equal! yay")
Here is one vote for leaving as is.
I've been saved more than once by this kind of warning:
if a = b: # << warning here
print("They are... equal! yay")
I know other languages such as C++ have the requested behavior, but GDScript is already loose as-is .. having it help catch (would have been timewasting) bugs like this is better than saving a few keystrokes to me.
@chanon yeah, that's the point. the assigning is working, but if it is used with 'if' or 'while' compiler will show the warning in the output. and it is up to developer to read it
Again, what about the following syntax?
if var error = do_stuff():
print("Error - ", result) # I.e. error != OK (OK = 0)
while (var some_var = some_func()) != null:
pass # Do stuff some day with some var
I don't like it because I use to type a single = by mistake and will never find the error in a = b = c 馃槄
First of all thank you for your report and sorry for the delay.
We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.
We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?
For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.
Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.
Thanks in advance.
Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.
Technically this is still relevant, but I'm against this proposal. It's quite easy to make a mistake in this regard, especially for beginners. While == is a established convention in programming languages, people who are new to programming can be thrown of by the fact that if a = b: does not do what they thought. Even experience programmers can miss it in a long code.
I vote to leave as it is now: assignments are explicitly forbidden inside expressions. Because the gain of this change is negligible and the issues raised by it can be quite problematic.
The if var a = b: is interesting, but it is not much of a gain. The only advantage is keeping the variable scoped to the inner block.
I agree, I don't think this would be a good change as it can lead to unnoticed errors. Outright disallowing this construct is much safer, as it is now.