Ergonomics of ArrayListUnmanaged

[Sze]

@jmctagger

Yes - do you have a favorite article/example/etc. that exemplifies this pattern well, for the record here?

Reserve First

@jmctagger

@Sze

Because try playlist.unmanaged.append(playlist.allocator, value); doesn’t seem easier than try playlist.tracks.append(playlist.allocator, value);

I might have missed something, or there might be a typo here, but I think most are envisioning a difference that looks more like try playlistA.append(alloc, value) vs try playlistB.append(value) …

I find it misleading to describe that with:

@jmctagger

pub fn Managed(Unmanaged: type) type {
    return struct {
        unmanaged: Unmanaged,
        allocator: Allocator,
    };
}

From that piece of code, I literally expected the result type to just be:

struct {
    unmanaged: Unmanaged,
    allocator: Allocator,
};

Instead of:

struct {
    unmanaged: Unmanaged,
    allocator: Allocator,

    // with wrapper methods that are the equivalent
    // of .unmanaged.xyz without needing to pass the allocator
};

Another reason why I find it misleading to use such a generic function to describe it, is that there is no obvious way for this generic function to produce the latter within Zig.

Zig doesn’t allow you to generate arbitrary functions using comptime meta-programming, so we don’t have a way to magically generate the needed wrapper functions from some arbitrary input type that implements some unknown unmanaged-container variant.

That was one of the points I was trying to make.

To solve this, one of these needs to happen:

• Zig could get more comptime-meta-programming features, so that we can write meta-programming code that automatically generates the managed variant (seems unlikely)
• all the functions for every managed variant need to be created manually, like they have been std/array_list.zig (this solution is deprecated)
• copy the deprecated solution and maintain it
  (likely some will do this, like it happend with BoundedArray)
• use zigft to write a generic function that is able to automatically create a managed one
  (I think this would be possible, but would have to check by trying it)
  (But this makes your code really dependent on zigft)
• use different (ugly) syntax like:

  var m: Managed(Unmanaged) = .init(allocator);
  try m.call(.append, .{my_item});
  

• give up and use unmanaged instead

Personally I think “give up and use unmanaged instead”, requires the least amount of effort and headache and it even can have benefits, once you go beyond the most basic use-cases.

Wanting managed containers seems a bit like a xy problem to me, it seems more to me like people actually want something more along the lines of Odin’s implicit-context-system, because if Zig had something similar all the unmanaged variants could be used in a managed-looking-style, but with Odin it seems to work via named-arguments with default-values that use the implicit context and it seems Zigs desire to be explicit, excludes this sort of implicit context.