de-genericify linked lists

[andrewrk]

With these changes, there's no longer any incentive to hand-roll next/prev pointers. A little bit less bloat too.

Migration Instructions

std.DoublyLinkedList(T).Node

⬇️

struct {
    node: std.DoublyLinkedList.Node,
    data: T,
}

Then use @fieldParentPtr to get from node to data.

In many cases there's a better pattern instead which is to put the node intrusively into the data structure. If you're not already doing that, there's a good chance linked list is the wrong data structure.

[nikneym]

These changes make sense, though I feel like need for @fieldParentPtr can be eliminated by forcing type T to have next: ?*T field in it's struct. We can also check for eligibility in comptime, e.g:

pub fn SinglyLinkedList(comptime T: type) type {
    comptime {
        if (@FieldType(T, "next") != ?*T) {
            @compileError("type T must satisfy next field with type ?*T");
        }
    }

    return struct { ... };
}

This is a typical pattern we see in large Zig projects too (libxev, TigerBeetle). That way, new implementation can attract projects to switch to stdlib implementation.

[mlugg]

These changes make sense, though I feel like need for @fieldParentPtr can be eliminated by forcing type T to have next: ?*T field in it's struct.

This assumes that using @fieldParentPtr is bad in some way. It's a completely reasonable operation with good type safety; no need to complicate things with comptime logic and requiring things of the container.

[L3P3]

What if the node is a member of a different list? I dont see how that is asserted here.

[kavika13]

It isn't asserted here, and the old code didn't either (it is basically the same code). So I think it's off topic for this PR.