This is a bit of a minor feature request for GDScript.
To help mitigate really long lines, it would be nice if you could write method chains on multiple lines, rather than being forced to have it all go on a single line. An example of this could be the following:
# go from this
block_size = get_node("Block").get_texture().get_size()
# to this
block_size = get_node("Block")
.get_texture()
.get_size()
Note the use of an indentation level to indicate that the chain belongs to the line above.
Doing this would let you write a really long method chain (if needed) without needing intermediate variables to store parts of the chain.
As the title suggests, this could also be useful in things like argument lists:
# going from this
Rect2((block_size + 255) / 2, door_width)
# to something like this
Rect2 (
(block_size + 255) / 2,
door_width )
This way if you're working with a super long argument list, you can break it up onto multiple lines to give a better overview.
Having to scroll sideways to be able to read the code isn't always super ideal, and not everyone has ultrawide monitors to work on, so this kind of breaking the code apart would be a nice addition.
you can break lines with \
I am aware
You can also break lines with ( and ):
var a = ( stuff()
.stuff()
.get_stuff()
.get_more_stuff()
.package(my_box)
.mail(location)
)
adding a hack doesn't really compensate for what's a basic language feature
A "Hack"? I disagree. A "Workaround"? Maybe.
Currently, this is near-impossible to do with the current parser, as it stops parsing the expression at the end of the line, except when it is inside parenthesis of some sort.
Also, it would be a breaking change, here is why:
func some_function_of_mine(a): # Override
.some_function_of_mine(a + 1) # Call parent func
do_something()
.some_function_of_mine(a + 2) # Call parent func again
So, is it do_something().some_function_of_mine(a + 2)? Or maybe it is two statements?
Or, if we do require additional indentation before the call, then this would be pretty weird to a normal human:
func a():
Expression.new("a")
.end() # Huh, why doesn't it error here because of the indent?
# Actually, is he calling the parent's .end, or the expression's .end?..
So, in short, somewhat doable, but doing it would be a "Hack" in the parser, and would probably backfire one day. That is, unless you can propose a better idea :wink:
You can also break lines with ( and ):
var a = ( stuff() .stuff() .get_stuff() .get_more_stuff() .package(my_box) .mail(location) )
Currently, you can't do it. See #35415.
Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Most helpful comment
A "Hack"? I disagree. A "Workaround"? Maybe.
Currently, this is near-impossible to do with the current parser, as it stops parsing the expression at the end of the line, except when it is inside parenthesis of some sort.
Also, it would be a breaking change, here is why:
So, is it
do_something().some_function_of_mine(a + 2)? Or maybe it is two statements?Or, if we do require additional indentation before the call, then this would be pretty weird to a normal human:
So, in short, somewhat doable, but doing it would be a "Hack" in the parser, and would probably backfire one day. That is, unless you can propose a better idea :wink: