In Zig, what's a writer?

This is only an issue in languages with duck-typing though. You're not really abstracting something if you need to go look how it's used to understand what to pass.

It’s crappy abstraction. Why make every user of the interface figure out how to use it properly? And guess what functions are required and which are always available?

Rust traits seem like a strictly better tool here. You get exactly the same emitted code as anytype, but the expected interface is explicit and well documented. Any time a trait name appears, you can cmd+click the trait name and see what functions are parts of the trait. It’s clean and explicit.

And traits can also have associated types (eg for an error type). They can have default implementations of functions. You can store a trait object in a struct. And you can use &dyn Trait if you want dynamic dispatch instead of monomorphisation. If this article is anything to go by, Zig makes all of this stuff difficult to impossible.

Anytype only solves the problem for the compiler. Traits solve the problem for the compiler and the programmer at the same time.

I suppose the : operator from lua would be useful.

int(* fnptr_name)(int param) becomes typeof(int(int param))* fnptr_name

There is a recent proposal to update standard headers to this style: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3450.txt

For the most common use cases C syntax is quite ergonomic once you've learned the principle.

    // declare func as normal function
    void func(ARGUMENTS);

    // declare (*func) as normal function: func is a pointer to a normal function
    void (*func)(ARGUMENTS);

    // can also declare a type name instead of a function
    typedef void functype(ARGUMENTS);

    // and then use that to declare function-pointer
    functype *func;

    // can also declare a function pointer type directly (I don't normally do this)
    typedef void (*funcptrtype)(ARGUMENTS);
    funcptrtype func;  // declare function pointer

What I'd love is a language which is able to compile 'impl TraitName' into dynamic dispatch in debug mode and only monomorphize it in release mode.

Basically, an automation of this technique: https://play.rust-lang.org/?version=stable&mode=debug&editio...

The rest of OOP is lipstick on arrays and arrays of arrays and "structs / records" or software defined arrays.

In my opinion.

In order to make this mechanism generic, you can instead say, "every implementer of the 'Reader' interface has a pointer as its first field, and that pointer leads to an array of two elements: the first element is a pointer to a 'Read' method, the second to a 'Close' method."

This way, the user of a Reader knows nothing of the internals of each implementation, other than how to find its methods

    typedef struct Writer {
      int (*method_one)(const char*, int);
      //...  
    } Writer;



    void takes_a_writer(const Writer *obj)  {
      // somewhere 
      obj->method_one(buff, buff_size);
      // ...
    }


    // a method implementation 
    int method_one_impl(const char *buff, int n) {
      //...
     }


     // somewhere else
     Writer w;
     w.method_one = method_one_impl;

     //...
     takes_a_writer(&w);

  const std = @import("std");
  
  // base struct
  const Animal = struct {
      // points to the derived struct
      ctx: *anyopaque,
      // points to the vtable of the concrete type
      vtable: *const VTable,
  
      // the vtable interface derived struct must implement
      const VTable = struct {
          make_noise: *const fn (ctx: *anyopaque, loudness: u32) anyerror!void,
      };
  
      // call the derived struct's implementation
      pub fn make_noise(animal: Animal, loudness: u32) anyerror!void {
          return animal.vtable.make_noise(animal.ctx, loudness);
      }
  };
  
  const Dog = struct {
      // extra data
      weight: u32,
  
      // implement the interface
      const vtable = Animal.VTable{
          .make_noise = &make_noise,
      };
  
      pub fn make_noise(ctx: *anyopaque, loudness: u32) anyerror!void {
          const dog: *Dog = @alignCast(@ptrCast(ctx));
          std.debug.print("woof {} {}\n", .{ dog.weight, loudness });
      }
  
      // helper to convert to the base struct
      pub fn _animal(self: *Dog) Animal {
          return Animal{
              .ctx = @ptrCast(self),
              .vtable = &vtable,
          };
      }
  };
  
  const Cat = struct {
      weight: u32,
  
      const vtable = Animal.VTable{
          .make_noise = &make_noise,
      };
  
      pub fn _animal(self: *Cat) Animal {
          return Animal{
              .ctx = @ptrCast(self),
              .vtable = &vtable,
          };
      }
  
      pub fn make_noise(ctx: *anyopaque, loudness: u32) anyerror!void {
          const cat: *Cat = @alignCast(@ptrCast(ctx));
          std.debug.print("meow {} {}\n", .{ cat.weight, loudness });
      }
  };
  
  pub fn main() !void {
      var gpa = std.heap.GeneralPurposeAllocator(.{}){};
      const alloc = gpa.allocator();
  
      // list of base structs
      var animal_list = std.ArrayList(Animal).init(alloc);
      defer {
          for (animal_list.items) |animal| {
              if (animal.vtable == &Dog.vtable) {
                  const dog: *Dog = @alignCast(@ptrCast(animal.ctx));
                  alloc.destroy(dog);
              } else if (animal.vtable == &Cat.vtable) {
                  const cat: *Cat = @alignCast(@ptrCast(animal.ctx));
                  alloc.destroy(cat);
              }
          }
          animal_list.deinit();
      }
  
      for (0..20) |i| {
          if (i % 2 == 0) {
              var dog = try alloc.create(Dog);
              dog.* = Dog{ .weight = @intCast(i) };
              try animal_list.append(dog._animal());
          } else {
              var cat = try alloc.create(Cat);
              cat.* = Cat{ .weight = @intCast(i) };
              try animal_list.append(cat._animal());
          }
      }
  
      // meows and woofs here
      for (animal_list.items) |animal| {
          try animal.make_noise(10);
      }
  }

It's not perfect since it's all in the userspace of the language (it'd be nicer to be able to express an interface type in the function signature), but it solves the problem you mentioned completely.