Support for zig-0.15

[jburgy]

On the heels of @bridgeQiao's excellent work on #441, we should discuss what to do about ziglang/zig#20663. @mlugg suggests an alternative for mixins that involves the slightly esoteric @fieldParentPtr. Unfortunately, it also requires replacing foo.incrementCounter() by foo.counter.increment() per this comment.

There are 13 occurrences of usingnamespace PyObjectMixin in Ziggy Pydust as well as countless calls to the corresponding methods (search for .incref() or .decref() to see a few). This is less intrusive than global mutable comptime state but tedious nonetheless. Who has clever ideas to minimize the effort?

[bridgeQiao]

There's no way to attach methods to code-generated types. If we could, the easy way would be to create a generic function that takes a Type parameter and returns a Type with the methods attached.

Changing foo.incref() to foo.obj.incref() would require modifying some existing code. Maybe the simplest immediate solution would be to add an incref method directly to each type in pydust/src/types.

composition was bad:

pub fn PyObjectMixin(comptime root: type) type {
  return struct {
    _data: root,
   
    pub fn incref() {}
  };
}

then PyBool would be:

const PyBool = PyObjectMixin(_PyBool);

using comptime funtion looks like same to too.obj.incref():

pub fn incref(root: anytype) void {
  root.obj.incref();
}

[bridgeQiao]

My writing is a bit scattered. To be specific, I mentioned four methods:

1. extend methods to code-generated types: it's impossible ziglang/zig#1170

2. rewite pub usingnamespace PyObjectMixin to functions define: e.g. add pub fn PyBool.incref(), pub fn PyBool.decref(). Although this approach requires modifications to all types, I still recommend this approach.

3. composition: This method is the one you were confused about. Taking PyBool as an example, the _data here is a member variable of PyBool. In this case, while PyBool.inref() would remain unchanged, PyBool.intobool() would become PyBool._data.intobool(). Therefore, I consider this approach to be bad one.

4. Introducing a generic function: But it looks same as the original approach. replacing foo.incrementCounter() by foo.counter.increment() becomes replacing foo.incrementCounter() by increment(foo).

[jburgy]

I see, thanks for clarifying. In order to move this argument forward, let's only debate 2 and 4. Ultimate, PyObjectMixin provides 6 methods: check, checked, checkedCast, unchecked, incref, and decref.

• I see no calls to uncheckedCast so we can kill that method
• checked and unchecked already exist as function in conversions.zig. We can probably enhance their implementations and replace py.PyTuple(root).unchecked(...) by py.unchecked(...)
• similarly, incref and decref exist in builtins.zig
• check is only used in __truediv__ where we can replace it by ffi.PyFloat_Check, resp. ffi.PyLong_Check

In other words, we are already halfway to 4. I will take a crack to see how much work that approach takes

[jburgy]

@robert3005 @bridgeQiao what do you think of #471?

[jburgy]

I did leave 1 usingnamespace in pydust/src/ffi.zig because that requires dealing with ziglang/zig#20630.

[jburgy]

c601d57 dealt with ziglang/zig#20630