Garbage Collection of nil Pointers

[gingerBill]

Is your feature request related to a problem? Please describe.
Implement a garbage collector as part of the Odin runtime which will free nil pointers to minimize memory usage.

Describe the solution you'd like
Anytime a pointer is nil and has no more usage within the program, the garbage collector can free these specific pointers.

Note: only nil pointers will be garbage collected; no other pointers.

[Kelimion]

Until the garbage collector is implemented, we may need to add free_nil_pointer and delete_nil_pointer to their respective proc maps so people don't go out of their way not to use it, thereby leaking memory. We can then mark them as deprecated.

[gingerBill]

That is a very good point for a transition period. Whilst the garbage collector for nil pointers is being developed, users will probably want to manually free their nil pointers and other compound data types containing points. Those would be brilliant transitionary procedures to add to ease the usage of code in the user's code base.

[Kelimion]

Also, in the interim, just like the Odin parser infers semicolons, we could have odinfmt add defer free(nil_pointer) everywhere it spots nil usage.

[ghost]

I don't quite understand the idea.

[matias-eduardo]

This is the only thing that’s keeping me from using Odin in production. Why do I have to write if ptr == nil do free(ptr); everywhere when a nil GC can take care of it? nil_ptrs always need to get freed immediately (no lifetime) so this is the one exemption where a GC actually makes sense.

[lerno]

Can’t we have borrowed nil pointers as well? It would help making nil thread safe, as well as enabling more modern memory features in Odin. std_move_nil_ptr which moves a nil pointer without making a copy.

[gingerBill]

@lerno That would have to be a much later edition. Borrow checking would have to be implemented after this feature. But it does enable more modern memory management approach in Odin.

[atkurtul]

And obviously, most importantly, for maximal type and memory safety i suggest that you require every memory operation to be wrapped in unsafe blocks.Otherwise it is indistinguishable from programmer's perspective what is safe and what is harmful.

[lerno]

I think @atkurtul raises an important point. Also, since every operation could possibly fail due to processor or memory malfunction, maybe each operation, including arithmetics, could also return an error value that you are forced to check before continuing to the next computation?

[awwdev]

also, you may consider to change the keyword and value of nil (0x0) to full (0xff..) before C++23 lands full :: distinct nil so Odin stays competitive

[nico-abram]

Could we have a type specifically for nil pointers? Maybe with dependant types

[gingerBill]

nil_t is a good idea!

[lerno]

Although all of these proposals are awesome, let's postpone them until next April 1st.

[gingerBill]

This was an April Fool's Joke.