Add increment(++) and decrement(--) operators to GDScript

[Chaosus]

Describe the project you are working on

Any project which using loops

Describe the problem or limitation you are having in your project

Nope, just a regular nuisance to write 'i += 1' in the loops.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Proposal to make that syntax possible:

var i = 0
while true:
	if do_something(i):
		break

	i++ # instead of i += 1

This feature is not from Python, but from the C-language family. But this syntax is obvious more compact and looking nice so I propose to add this to GDScript. There should be post-*crement (i++, i--) and pre-*crement (++i, --i). They should act like in the C-language (https://en.cppreference.com/w/cpp/language/operator_incdec).

I knew that was discussed a while ago and @reduz said that would overcomplicate the GDScript - but this is just a proposal right? - then if users would like it and vote for it then it should be reconsidered.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

^^

If this enhancement will not be used often, can it be worked around with a few lines of script?

Nope

Is there a reason why this should be core and not an add-on in the asset library?

It's a core GDScript enhancement

[KoBeWi]

See #2869

[YuriSizov]

Closed as a duplicate, see discussions linked above (there are more related issues linked inside of that proposal). Discussion can be continued in one of the previously closed proposals, as the arguments are generally the same between all of them. Though before we reopen any of them it would make sense to talk to vnen if there is any point in doing that because I feel like the current decision is not to add it in future versions, and that's final.

[Xrayez]

I knew that was discussed a while ago and @reduz said that would overcomplicate the GDScript - but this is just a proposal right? - then if users would like it and vote for it then it should be reconsidered.

@Chaosus looks like Godot is not community-driven per se (aka final decisions are not made by community), the final decision is up to core developers like vnen... Quoting pycbouh in #2531 (comment):

Community doesn't maintain Godot, maintainers do. Community does drive the decision making process, but it doesn't rule it. Misinterpretation of the definition is the core of the problem here, when you put it like that. Definition of Godot as "community-driven" doesn't put community in charge. It puts community interests in front, but it doesn't mean that there is democracy or design-by-committee process. In fact, I am strictly against it and in favor of opinionated decision making process with few decision makers. [emphasis mine]

Also quoting @Xananax there:

With all of this in mind, I personally think Godot should thrive to be less community driven [emphasis mine]. In other open source projects, which also bear the "community driven" moniker, but give less leeway to people, ridiculous situations such as this one don't happen nearly as often.

It's probably much easier to make opiniated decisions, so I cannot blame them. 😄

---

Though before we reopen any of them it would make sense to talk to vnen if there is any point in doing that because I feel like the current decision is not to add it in future versions, and that's final.

#2531 (comment):

It puts community interests in front

I'd keep this open for the sake of avoiding duplicate proposals, then. Because there are quite a bunch of people (including myself and Chaosus) that think otherwise. The existence of #2894 and #2869 are clear evidences of that. 😛

As I've heard from other Godot representatives/moderators on Discord (from which I got banned, btw), Godot's development is considered highly organic, so everything is possible.

EDIT: reopened #2869.

[Chaosus]

@Chaosus looks like Godot is not community-driven per se (aka final decisions are not made by community), the final decision is up to core developers like vnen... Quoting pycbouh in #2531 (comment):

In the case of this proposal, I wanted to see users' reactions (voting). I still believe that if user voting has positive demand and can be relatively easy to implement then it has a high chance to be accepted by the core developers.

[YuriSizov]

can be relatively easy to implement

This is the reason why it hasn't been. It's not. But please keep the discussion to a single proposal. Since Xrayez re-opened the other one, let it be the other one.