Godot-proposals: Just a thought, Free() could have a Force/Queue Bool attached to it.

[jjbob1234]

Describe the project you are working on:
A simple ball rolling around, smashing things.

Describe the problem or limitation you are having in your project:
No problem per-say, this is for people with less patience then me.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I saw a post from back when you accepted proposals on the main github issues page; Suggesting that you change queue_free() to free() and free() to something else.

Now i understand that this would bring up some issues with developers that are used to the way it is, but my suggestion isn't to change the functions rather i think it would be handy for free() to include some modifiers to access the other code for new people.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Like for instance queue_free() could be free(false) and free() could be free(true)

Default to free(Forced = true) to not break any old code

If this enhancement will not be used often, can it be worked around with a few lines of script?:
I don't think it would change anything unless queue_free() becomes outdated in the community.

Is there a reason why this should be core and not an add-on in the asset library?:
just to introduce new people to the idea of queue freeing without needing to reference the internet, i've been using .free() in my project and it would be more simple to add (false) to all of them instead of adding queue_ to all of them.

Closing statement:
Just thought the idea might help give new game programmers an easier time using GDScript as their first language, perhaps its not a requirement and easy to accomplish the same with little effort, but just an idea to think about, i hope you all like my suggestion.
1 step towards more user friendly code could be the support a brand new developer needs even if no-one else uses it.
there could be a lot of little stuff like this that might not change much but help a few people figure out new ways to use functions more effectively.

_And i would love to have discussion about this._

[clayjohn]

Im not sure it would be easier for new programmers. The nice thing about queue_free() is that it is descriptive. free(false) doesn't obviously indicate that it is queuing the freeing of the node. I can see this giving rise to a lot of confusion.

On the flip-side I can see how queue_free() may be hard to discover. Once you start using free() you may never consider that there could be other options for freeing nodes.

[jjbob1234]

Im not sure it would be easier for new programmers. The nice thing about queue_free() is that it is descriptive. free(false) doesn't obviously indicate that it is queuing the freeing of the node. I can see this giving rise to a lot of confusion.

On the flip-side I can see how queue_free() may be hard to discover. Once you start using free() you may never consider that there could be other options for freeing nodes.

yes, but, i was suggesting both be an option, so if a developer starts by using free() they will notice when typing ( that it asks if it should be forced with a default of true. at least putting the idea that they have the choice in their head.

[jjbob1234]

Maybe it would be better to just add a warning that lets you know .queue_free() is a safer option if you use .free() and a way to deactivate the warning in the case you know what the difference is already?

[Jummit]

Remember that it is Object.free and Node.queue_free.

[linkpy]

I agree with @clayjohn here. queue_free is descriptive and understandable. Adding a boolean argument to free would make it more confusing.

Further more, like @Jummit pointed out, it's not really possible. queue_free comes from Node, and not Object. I'm not an expert in C++, but IIRC, you can't change a function's signature when overloading it (just like in GDScript), so Node can't overwrite free to make that implementation possible.

[Calinou]

Thanks for opening a proposal :slightly_smiling_face:

I'll have to close it, since implementing this is not technically possible as @linkpy pointed out. Moreover, code readability would likely suffer due to this change.