There's a feature that some other new languages implemented and that proved to be very powerful, which is a template preprocessor. I mention Nim because it had some nice implementation of it. But in a nutshell it's about replacing some keywords with custom text/script during the startup time when a project is launched.
This aims for more concise, cleaner and more reusable code.
Syntax sugar + in runtime...
Instead, how about macro function returning code string which is injected to the script at compile time?
Similar to #10948. IMO this an unneeded over-complication of the language.
Macros are a beast of a feature but also introduce a ton of problems and this makes a language like GDScript worse.
Most of the times you find yourself wanting to do something new as a newbie coder what do you do, you try to use some Macros end up with a program filled with macros and then you start crying when the program you coded has tons of problems that you can't solve.
Overall if you are a beginner not having Macros is a big help to not distract you from learning proper programming.
The grounds on which I can't stand them are,
@vnen , yes, it looks like a duplicate from #10948 . But it is essential that macros are located in another file and not in the script which uses it.
However I think it would allow different kind of writing, like for instance state machine configuration.
@swarnimarun , I'm aware that it makes debugging more difficult and it can introduce side effects, but what alternatives offer to write functional programming and the said state machine configuration concisely and in a human readable way?
Also, well tested macros have the advantage to not have to be debugged. If someone writes a framework based on macros and he does his job perfectly, you can use those new keywords without having to worry about them. And by extent it can help artists and real beginners to use a framework that makes most of the work for them. A bit like the visual language.
@gokudomatic I am not saying that I don't like Macros, I love them but they aren't a good fit for a simple and easy to use language, you can always create abstraction using other methods and make it human readable.
My point is simply, don't add a feature unless you absolutely need it.
This might be helpful for syntactic sugar but other than that I don't know of any specific use cases for it, in the realm that belongs to GDScript.
My point is simply, don't add a feature unless you absolutely need it.
Please let other people discuss what they need or not before arrogantly deciding it for them.
@starry-abyss The thing is it's not only for one or two or for three people, it's a feature for everyone. I can say that I don't need it and ask you to think if you absolutely need it.
I would have been arrogant if I had said that it's a waste of time and put a sock and move on, close this thread. But rather I am just stating stuff in my head.
Macros have always been a debate starting topic and I don't think there is any programmer that hasn't changed his views on the matter with experience or time or advice.
Why don't you or OP try to convince me and the devs by giving some examples and code, feature proposals are made to convince the people especially in the open-source community.
I would love to have Macros but why bloat GDScript?
Why do you need them?
Is there something that languages that don't have macros just can't do that is relevant in the context of Godot and Game Development?
Overall this is a bad feature request not cause it's a bad feature but cause no one even gives a proper reason to have the above-mentioned feature. No examples with code...
And functional programming doesn't absolutely require meta-programming and Macros but it's more of a feature there to help with making the code better.
Good Macros and meta-programming systems are there to help the advanced and the beginner programmers alike but need some experience to get good at.
Overall the adding more things to GDScript will make it slower and increase the level of complexity.
And adding Macros means adding a huge feature to GDScript, it will not only be a feature but a whole new concept in itself, Meta Programming.
This means we need to think of all the reason to not do it and check them out before anyone tries to implement it.
This one talks about lots of reason for why Macros are not there in lots of modern languages, https://softwareengineering.stackexchange.com/questions/937/why-arent-macros-included-in-most-modern-programming-languages
I want one list that can counter that list or just show me(and people here) enough pros that make it worth it to have a feature like this in GDScript.
And, I hope no one finds it arrogant.
Well, @swarnimarun has an important point: no one here is saying why they need this. As stated in the FAQ, requests should come from use cases. Not only that, but the feature should be used often or be really difficult to work around, and I think a language preprocessor is neither of those.
@vnen My use case here is the configuration of a state machine.
Why don't you or OP try to convince me and the devs by giving some examples and code, feature proposals are made to convince the people especially in the open-source community.
Use case: in the project I work on (not Godot one), macros are used to get a list of all entity classes (about 300 total) to populate them in an in-game editor menu.
Convince? I don't know if I need this in GDScript (yet). Neither do I know if I don't need it.
And functional programming doesn't absolutely require meta-programming and Macros but it's more of a feature there to help with making the code better.
Programming doesn't absolutely require IDEs, profilers, code reviews, unit tests, and whatnots, they are more of a feature to help with making the code better.
And adding Macros means adding a huge feature to GDScript, it will not only be a feature but a whole new concept in itself, Meta Programming.
I worked in Haxe with AST macros - they are over-complicated, and text-based ones - they are not at all.
Sure, for them to be really useful, there are some helper concepts like class-building function. Nobody said it's a couple lines of code to add.
why Macros are not there in lots of modern languages
Time to revisit the "modern" part. D, Rust, Nim, to name a few, have some type of macros.
I want one list that can counter that list or just show me(and people here) enough pros that make it worth it to have a feature like this in GDScript.
Just wait for some months for other people to give their 2 cents (or for this feature request to be just buried and forgotten among others). What is the point of generic comments like "I don't know what it does, but I know we don't need this"?
@starry-abyss I again quote lots of modern languages. Not all or most.
Use case: in the project, I work on (not Godot one), macros are used to get a list of all entity classes (about 300 total) to populate them in an in-game editor menu.
- I have used Unity for a long time, done all the things like getting the entity classes, adding them to an editor menu and lots more and C# has no Macros.
Programming doesn't absolutely require IDEs, profilers, code reviews, unit tests, and whatnots, they are more of a feature to help with making the code better.
- That's the reason many people don't use IDEs. And still, make awesome things. Like my favourite programmers like Jonathan Blow and Casey use Emacs or Vim or something like that.
- Even I like to use VS Code cause I am not a fan of most modern IDEs. They are bloated and slow.
- While others(profiler and unit tests) you mentioned come under best practices for coding they aren't like Macros. They are more of like browsers, you can go through the web through Terminal too but you will miss a lot of things(graphics and stuff) so it's not an alternative. Just like Profilers have no alternatives.
Just wait for some months for other people to give their 2 cents (or for this feature request to be just buried and forgotten among others). What is the point of generic comments like "I don't know what it does, but I know we don't need this"?
- Why aren't you someone who starts and shows me an example of something that you should be able to do in Godot but can't cause you don't have macros.
- And who said I don't know why and how Macros are used, my current favourite language is Rust and I use them a ton. It's just that I don't feel a need for them in GDScript.
No one here is saying "I don't know what it does, but I know we don't need this"?
I just want to know where are you coming from saying that add this to Godot.
@gokudomatic that's a good thought but from my perspective you can also use methods to make do, please be more specific. Some code helps nothing major just a basic example.
Hope this clears things up.
my favourite programmers like Jonathan Blow
Then you should watch this talk, it's about their new programming language, which _does have_ macros. ;)
I just want to know where are you coming from saying that add this to Godot.
I'm coming from making games in not editor-oriented engines. That's why I'm not sure if _GDScript_ needs this feature or not. _Godot_ does use some metaprogramming though at Scons side, for the lack of modern macros in C++.
@starry-abyss Ok now I get your point.
I have watched that talk already, twice actually was hard to wrap around my head in just a single run.
And as I said I love Macros they are super helpful when needed but GDScript needing them is a different issue.
And just as you said I am also looking forward to seeing how some more experienced guys than me react to this proposal.
Do they think that GDScript needs Macros, personally I don't. But I am an open-minded person.
And so I did love to see some examples of code that proves that Macros will be a essential part of GDScript.
And yes I know that Godot uses them at the scons side not very knowledgeable with scons build system though.
for the lack of modern macros in C++.
- Another reason I like Rust.
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!