YoYo should not bow to suggestions that arise from ignorance of basic techniques, in this case asynchronous handling of sequential actions.
This suggestion is only ever meaningful for people who over-complicate their code by never delegating between events and components. It's an emotional outburst from novice users when they run into walls with poor code architecture, in particular the kind dictated by the cult of "everything-in-one-place". Anyone who is past that stage and does delegate can see a variety of existing alternatives in GM, some even designed explicitly for the purpose:
- Timelines
- Worker objects
- Asynchronous events
- Manual/built-in alarms
- Scripted solutions such as TMC Script Batch
And with the upcoming introduction of chained accessors and lambdas, promise-like mechanisms such as the kind in modern Javascript will also become a viable alternative, with generality surpassing all of the above options yet also permitting the delayed actions to be specified in the same piece of code.
The suggestion also fails to think of contradictions with existing syntax and functionality. Consider the following:
Code:
///@func foo()
wait(4);
return "FOO";
Code:
///@desc Draw event
for (var i = 0; i < 10, i++) {
draw_text(x, y, foo());
}
If it returns "FOO" right away, then the wait didn't happen, thus violating the suggestion's premise. If the wait does happen, a run of the Draw event code will be delayed past schedule, likely to a point where it becomes inconsistent with the engine's internal state. There's no way for conflicts like this to be resolved in a way that is consistent with clear-cut, reliable execution.
Compared to learning how to do asynchronous sequential actions properly with existing and well-defined techniques, introducing loosey-goosey, self-contradictory syntax to GM is a far worse alternative.