-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Allow second line brackets #1209
Comments
You need to use more rational arguments for this 🙂 Most languages with an indent-based syntax won't allow you to write the following: var arr =
[ #this
0,
1,
2,
]
var dic=
{ #this
"a": 0,
"b": 1,
"c": 2,
} However, you can use backslashes to escape newlines so this becomes valid syntax: var arr = \
[ #this
0,
1,
2,
]
var dic= \
{ #this
"a": 0,
"b": 1,
"c": 2,
} Still, just because you can doesn't mean you should. I don't see an issue with the established syntax for writing arrays or dictionaries on multiple lines. |
I don't know of any language that supports this, indent-based or not. |
@jonbonazza This apparently works in C (just tested it with GCC and Clang): struct example {
int a;
int b;
};
int main() {
struct example ex =
{
2,
4,
};
return 0;
} However, this is possible only because C doesn't use an indent-based syntax. |
Theoretically, we can allow line breaks for binary operations ( var a = true && # Expected to continue; the line break is ignored.
false # End of expression.
var b = true
&& false # Will be added to the previous line. But IMO it is less readable than with parentheses. |
Closing, as this isn't worth the added parser complexity in an indentation-based language like GDScript. Backslashes or parentheses can already be used to wrap expressions over multiple lines. |
Describe the project you are working on:
A space ship project
Describe the problem or limitation you are having in your project:
I just don't like it
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
allow for second line brackets and braces like so..
currently this throws a error unless you change it to this..
I think this is not only is utter crap in the way it forces the way you format but it also is less readable for me
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
basically the parser would just allow for this to happen and wouldn't complain.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
I would use it and I'm sure other c developers and no it can't be worked around
Is there a reason why this should be core and not an add-on in the asset library?:
its less confusing to not get a error when this happens
The text was updated successfully, but these errors were encountered: