Zig (programming language): Difference between revisions

Content deleted Content added
top: Fixed a comma splice
Tags: Mobile edit Mobile app edit Android app edit App full source
Add 'citation needed' template to claim of modernity. (Note: Other languages have had 'maybe', 'optional', and 'nullable' types for many years. E.g. Haskell's 'Maybe' type has been around since at least 2006.)
Line 50:
A common solution to these problems is a [[Garbage collection (computer science)|garbage collector]] (GC), which examines the program for pointers to previously allocated memory, and removing any blocks that no longer have anything pointing to them. Although this greatly reduces, or even eliminates, memory errors, GC systems are relatively slow compared to manual memory management{{citation needed|date=August 2024}}, and have unpredictable performance that makes them unsuited to [[systems programming]]. Another solution is [[automatic reference counting]] (ARC), which implements the same basic concept of identifying blocks of disused memory, but does so at pointer creation and destruction time by maintaining the number of pointers to a block, meaning there is no need to perform exhaustive pointer searches, which are rendered unnecessary at the cost of adding reference counter adjustment overhead to every pointer creation and destruction operation.<ref name=gc>{{cite web |url=https://docs.elementscompiler.com/Concepts/ARCvsGC/ |title=ARC vs. GC |website=Elements}}</ref>
 
Zig aims to provide performance similar to or better than C, so GC and ARC are not suitable solutions. Instead, it uses a modern,{{citation needed|date=May 2025}} {{as of|2022|lc=yes}}, concept known as [[option type]]s. Instead of a pointer being allowed to point to nothing, or nil, a separate type is used to indicate data that is optionally empty. This is similar to using a structure with a pointer and a boolean that indicates whether the pointer is valid, but the state of the boolean is invisibly managed by the language and does not need to be explicitly managed by the programmer. So, for instance, when the pointer is declared it is set to "unallocated", and when that pointer receives a value from a malloc, it is set to "allocated" if the malloc succeeded.<ref name=javao>{{cite web |url=https://www.baeldung.com/java-optional |title= Guide To Java 8 Optional |date=28 November 2022}}</ref>
 
The advantage to this model is that it has very low or zero overhead; the compiler has to create the code to pass along the optional type when pointers are manipulated, as opposed to a simple pointer, but this allows it to directly express possible memory problems at compile time with no runtime support. For instance, creating a pointer with a null value and then attempting to use it is perfectly acceptable in C, leading to null-pointer errors. In contrast, a language using optional types can check that all code paths only attempt to use pointers when they are valid. While this does not eliminate all potential problems, when issues do occur at runtime the error can be more precisely located and explained.<ref name=rusto>{{cite web |url=https://ggbaker.ca/prog-langs/content/rust-memory.html |title= Rust: Memory Management}}</ref>