Strike @init, @fini, and non-constant global variable initializers from the language

[Feoramund]

@init and its relatives have caused a number of issues in the language.

• Can't control allocator used in procs tagged with @(init) and globals #5136
• Global variable initialization does not follow @(init) order #5146 (This issue is blocking Add native lock-free dynamic heap allocator #4749.)
• Shared libraries run inits in system-dependent order #5174
• Global initializers not referenced fail to produce side-effects #5337
• @(init) tracking issue #5352
• Add @(default_context) and intrinsics.__default_context #5296 (created as a resolution to Can't control allocator used in procs tagged with @(init) and globals #5136 but ran into its own platform-specific issues)

I propose to strike @init, @fini, and non-constant global variable initializers from the language.

Specifically, a non-constant global variable initializer is anything of a form which requires runtime resolution to determine its value.

// Assume we are at package/file scope.
g: T = p() // Forbidden.
g: T // Okay.

---

In place of all of the above, I propose the following paradigm which should be no stranger to any C programmer:

package main

import "base:runtime"
import "core:os"

main :: proc() {
	runtime.init_heap()
	os.init_args()

	defer {
		os.fini_args()
		runtime.fini_heap()
	}

	// Begin main program here.
	// ...
	// End of main program.
}

Not only will this hand over all control back to the programmer as to specifically how they handle their context and allocators thereof (fixing #5136 and completely negating the need for my PR #5296, a win for simplicity), it will make the precise execution order explicit and in the hands of the programmer, as is a keystone of the Odin programming language.

From then on, any API which requires initialization must produce an init_* procedure in its package which would do what is needed for it to function correctly.

In the end, @init and others only serve to magically hoist certain specified logic into _startup_runtime and _cleanup_runtime which could be done just as well in the entry point by the programmer without all the extra complexity and sugar.

---

@gingerBill @karl-zylinski @Kelimion

[gingerBill]

So there are a few things here to break down but fundamentally half of the problem is the inconsistent global initialization order, and the inability to specify priorities of things like @(init) and @(fini) too.

I do not want to remove these features because most C compilers even have such constructs for many rare edge cases that require them.

And to break down each of the issues:

• Can't control allocator used in procs tagged with @(init) and globals #5136
  • This is more of a case of the use of @(init) where it should be allowed.
  • Maybe the better option is to require @(init) procedures to be "contextless" and thus everything is a little more explicit
• Global variable initialization does not follow @(init) order #5146
  • This is a "fun" mathematical problem where I am not sure how to solve at this moment. I wanted to do a proper deterministic topological sort on everything and its dependencies, but I couldn't get it to work just the way that "felt" right. I think this needs to be tackled again.
• Add native lock-free dynamic heap allocator #4749
  • This is another "fun" one.
  • One of the reasons for global_variable := runtime_call() is that if you don't use global_variable, it doesn't actually get initialized. However @(init) is effectively mandatory, since it has to be called.
  • I'll have to talk you specifically about that heap allocator in general and how to tackle it specifically.
• Shared libraries run inits in system-dependent order #5174
  • This is related to the deterministic topological sort again which is lacking for @(init)
  • The current rule is order of the sorted files and then top-down in the source. A topological sort might produce a slightly better result but not necessarily.
  • It's also another indication of the over use of @(init)
• Global initializers not referenced fail to produce side-effects #5337
  • Referencing the thing earlier, that's kind of the point of what I added them in the first place.
  • The most canonical example I can think of is os.args. That does require an allocation on use but if that is not used, it does not need to be allocated (and thus freed at the end).
• Add @(default_context) and intrinsics.__default_context #5296
  • This is mostly to get around the @(init) problem which I think should be solved with requiring them to be "contextless" and thus people then become explicit about what they need in their context before even main is ran.

[gingerBill]

I'm working on some of the changes here: #5558

[gingerBill]

This has now been merged: #5558

[herohiralal]

+1 on this because would prefer deterministic code execution order in general

OpenGL and SDL have required you to call their app-level init functions for years now

Not that big a deal if odin base/core packages (or even third-party packages) demand the same (or employ an initialise-on-requirement model).