Slices in Zig are one of the language’s fundamental concepts and are implemented as “fat pointers.” This article explores what slices are, how they work as fat pointers, and their practical applications in Zig programming.

What is a Fat Pointer?

A fat pointer is a pointer that carries additional metadata alongside the memory address. In Zig, a slice is a fat pointer that contains:

1. A pointer to the underlying data
2. The length of the slice

Slice Syntax and Structure

In Zig, a slice is denoted using the syntax []T, where T is the type of elements in the slice. Internally, a slice can be represented as:

struct {
    ptr: [*]T,    // Pointer to the data (many-item pointer type)
    len: usize,   // Length of the slice
}

There’s also a sentinel-terminated variant: [:sentinel]T, where sentinel is a terminating value.

Creating and Using Slices

1. From Arrays

const array = [_]i32{ 1, 2, 3, 4, 5 };
const slice = array[1..4];  // Creates a slice of elements [2, 3, 4]

2. From Pointers

fn processSlice(slice: []const i32) void {
    for (slice) |value| {
        // Process each value
    }
}

3. Sentinel-Terminated Slices

const string: [:0]const u8 = "Hello";  // null-terminated string slice
const peek = string[0..3:0];  // Creates a new null-terminated slice

Key Features of Slices

Bounds Checking

Slices in Zig provide automatic bounds checking in safe modes (debug and release-safe). This helps prevent buffer overflows and underflows:

const array = [_]i32{ 1, 2, 3 };
const slice = array[0..];
// This would trigger a runtime error in safe modes:
// const invalid = slice[5];

Immutable Length

The length of a slice is immutable once created. This provides safety and predictability:

var slice: []i32 = &array;
// slice.len = 10;  // This would be a compilation error

Zero-cost Abstraction

Slices are a zero-cost abstraction in Zig, meaning they don’t add runtime overhead beyond what’s necessary for their functionality:

const array = [_]i32{ 1, 2, 3, 4, 5 };
const slice = array[0..];
// The slice's length is known at compile-time when possible

Pointer Types in Slices

Zig has different pointer types that can be used with slices:

• [*]T: many-item pointer (used internally in slices)
• *[N]T: pointer to array
• *T: single-item pointer
• []T: slice (fat pointer)

Common Use Cases

1. String Handling

Strings in Zig are often represented as slices of bytes:

const string: []const u8 = "Hello, World!";
const substring = string[0..5];  // "Hello"

// Null-terminated string slice
const cstring: [:0]const u8 = "Hello\x00";

2. Dynamic Arrays

Slices work well with dynamic arrays (ArrayList in Zig):

const ArrayList = std.ArrayList;
var list = ArrayList(i32).init(allocator);
defer list.deinit();

try list.append(1);
try list.append(2);

const slice = list.items;  // Get slice of the ArrayList

3. Function Parameters

Slices are commonly used as function parameters to accept arrays of different sizes:

fn sum(numbers: []const i32) i32 {
    var total: i32 = 0;
    for (numbers) |num| {
        total += num;
    }
    return total;
}

Best Practices

1. Use Const When Possible

   fn readOnly(data: []const i32) void {
       // Can't modify the slice contents
   }
   

2. Explicit Lifetime Management

   fn getSlice() ![]i32 {
       var slice = try allocator.alloc(i32, 10);
       // Remember to free later with allocator.free(slice)
       return slice;
   }
   

3. Slicing Conventions

   const full = array[0..];     // Full slice
   const partial = array[1..4]; // Partial slice
   const last = array[array.len-1..];  // Last element
   

4. Sentinel-Terminated Slices

   // Creating a sentinel-terminated slice
   const terminated = "hello"[0..3:0];  // Creates a null-terminated slice
   

Common Pitfalls and Solutions

1. Dangling Slices

Be careful not to return slices to temporary data:

// Bad:
fn getDanglingSlice() []i32 {
    var array = [_]i32{ 1, 2, 3 };
    return &array;  // Would return dangling pointer
}

// Good:
fn getSafeSlice(allocator: *std.mem.Allocator) ![]i32 {
    var slice = try allocator.alloc(i32, 3);
    return slice;
}

2. Slice Bounds

Always verify slice bounds when creating sub-slices:

fn safeSlice(data: []const i32, start: usize, end: usize) ![]const i32 {
    if (end > data.len or start > end) {
        return error.InvalidBounds;
    }
    return data[start..end];
}

3. Sentinel Handling

Be careful when working with sentinel-terminated slices:

const string: [:0]const u8 = "Hello";
const slice = string[0..3];  // Regular slice, loses sentinel
const terminated = string[0..3:0];  // Maintains null termination

Performance Considerations

1. Slices are passed by reference, making them efficient for large data structures
2. Bounds checking can be disabled in release-fast mode for maximum performance
3. The fat pointer structure allows for efficient iteration and access patterns
4. Sentinel-terminated slices may have slightly different performance characteristics due to the additional terminator checks

Conclusion

Slices as fat pointers in Zig provide a powerful, safe, and efficient way to work with arrays and memory ranges. They combine the flexibility of dynamic sizing with the performance of direct memory access, while maintaining memory safety through compile-time and runtime checks. Understanding how to effectively use slices, including their sentinel-terminated variants, is crucial for writing idiomatic and efficient Zig code.

Remember that while slices provide many safety features, it’s still important to manage memory correctly and be aware of slice lifetimes, especially when working with allocated memory.