[3.2] Export sections

[SekoiaTree]

This PR introduces export sections, which are a way to organize exported variables in the inspector. There is technically a way to do sections already, however this method is controverted (https://docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_exports.html#adding-script-categories) and takes a lot of space. This PR introduces the cosmetic syntax.
The code permits easy additions for other cosmetics, such as a line break or a comment (not given in this PR).
It's also coded in a seamless way, that isn't out of place or hacky.

The syntax is the following: cosmetic (section, "sectionname"): followed by an indent and any variable declarations wanted. This is purely cosmetic, and targeting of variables is the same as usual.

This feature has been appreciated by the community, as shown by the reddit post getting over 100 upvotes ( https://www.reddit.com/r/godot/comments/hwgh8l/edited_the_engine_a_bit_to_add_sections_wont_be/) with multiple comments asking for this to be added, and by discussing with people in the discord.

This feature makes making nodes with a lot of variables much easier, which happens often for modular nodes, such as customizable particle emitters or player characters (particularly in 3D).

Bugsquad edit: This closes #4378.

[SekoiaTree]

Putting in a patch soon. Forgot to add one thing, plus a lot of checks are failing. Will edit this once patch has been pushed.
Edit: Pushed. Hopefully the checks will pass this time.
Edit 2: Some formatting issues. Will patch tomorrow.
Edit 3: Patched. Checks pass now

[groud]

Well... GDscript is being rewritten for 4.0. As it should feature annotation, which it a perfect use case for this, there is not much interest in merging this in master. And that kind of new feature must go through our proposal workflow (it's not because a lot of people want the feature that it should be implemented this way ;) )

We usually don't accept new features on 3.2, but we sometime accept simple ones. Considering this is not a very straightforward change and that this will be implemented already in 4.0, I am not sure it is worth merging.

[Zireael07]

@groud: proposal made at godotengine/godot-proposals#1255

[SekoiaTree]

@groud yeah, I definitely want to do this for 4.0. However, I started this before 4.0 had GDScript 2.0 merged. I also feel like this is useful enough to be merged for 3.2.

And that kind of new feature must go through our proposal workflow

You're completely right in that, and I definitely should have. I did however talk to people about syntax, and this is the syntax that fits inside regular GDScript, with an easy way to add other cosmetics.

Considering this is not a very straightforward change

Can you elaborate on that? I honestly don't see how this isn't straightforward.

that this will be implemented already in 4.0

I didn't know this. Do you have a source?

[groud]

Can you elaborate on that? I honestly don't see how this isn't straightforward.

This change is modifying significant parts of of the engine, modifying the GDscript interpreter by a lot of lines spread over 7 files. So it's not a delimited, simple change, it might impact core functionalities if it introduce bugs. That's what I meant by that.

I didn't know this. Do you have a source?

This wasn't easy to find, but vnen, who is implementing GDscript 4.0, proposed the change in his "annotations for GDscript" proposal. See this comment there: godotengine/godot-proposals#828 (comment)
It's not 100% sure to be implemented this way, but I think most people agree that the feature would be good to have.

[SekoiaTree]

It's not actually that many new lines. A lot of the code comes from a copy-paste of two of switch-cases. The changes are mostly on 2 files (gdscript_tokenizer and gdscript_parser), the rest being one-line changes needed to add syntax. The added code is also completely consistent with the rest of the code, completely sealed off apart from 1 case inside a switch.

Thanks for the source, that is indeed the same thing. I still feel this would be good to have in 3.2, albeit with a different syntax.

[m50]

I think this implementation leaves a lot to be desired. First off, there is no way this would work in C# at all. Additionally, the variables aren't semantically and cosmetically aligned. Cosmetically they are grouped, however to have them grouped semantically in the code, it requires them to share parts of names.

If we supported exporting of structs instead, it would make a lot more sense, would be language cross-compatible (syntactically at least), and would be semantically and cosmetically algined.

Ex GDScript:

struct Friction:
    var max_speed: int = 1000
    var friction: float = 0.99
struct Movement:
    var speed: int = 100
    var friction: Friction
// OR
struct Movement:
    var speed: int = 100
    struct Friction:
        var max_speed: int = 1000
        var fric: float = 0.99

export var movement: Movement
// OR
export(struct, Movement) var movement

func _ready():
    movement.friction.max_speed = 500

Ex C#:

public struct Friction
{
    int MaxSpeed { get; set; }
    float Fric { get; set; }
}

public struct Movement
{
    int Speed { get; set; }
    Friction Friction { get; set; }
}

[Export] public Movement movement;

public override void _Ready() => movement.Friction.MaxSpeed = 500;

This would then display as groups/sections in the editor.

If this were to get implemented, I'd rather see it implemented using structs, but at that point, it would be a 4.0 feature.

[SekoiaTree]

This was in fact discussed with other people, and the general consensus was that in this should be purely cosmetic (hence the name of the tag), as the goal is to help organization of exported variables. What you've suggested here is purely a struct, and I do agree that structs could be very useful, I don't feel like those would fit in with the goal of this PR.

On top of that, with GDScript being completely rewritten for 4.0, the syntax you've proposed would no longer be valid anyway.

Support for C# is something I considered, but because I don't use C#, figuring out how the parser/tokenizer works would take too much time to be merged into 3.2. If this PR were to be adapted to 4.0, C# would definitely be in my goals, however.

[Zireael07]

Why close, @SekoiaTree ?

[SekoiaTree]

Er, mostly because the code is not very good and it was denied

[Boivin92]

Mark me down as sad. I don't especially like the annotation solution brought forward by the core contributors, for many reasons, so your solution was what I didn't knew I needed. It seemed so much more natural to have the variable structure be reflected in the file structure, rather than by having variable prefixes or tagging them with a category.

[Calinou]

@Boivin92 Unfortunately, the way the structure is reflected is fundamentally incompatible with how exported variables are created in C# (and by extension, GDNative).

[Boivin92]

@Calinou Don't get me wrong I understand the reasons why this isn't merged, but for a fleeting second I had hope that we might have an easy, non-annotation way to create groups of exports.