comptime interfaces

Proposal on comptime Interfaces / Traits (the terminology is left to the reader / implementer)

motivation

Zig currently has very bad code for expressing some sort of shared properties.

Look at mem.Allocator and heap.xyz for the implemenations if you have not already. (there are other places where this smells of course as well)
Notice the use of @fieldParentPtr and function pointers which make the code hard to read and unnecessarily inefficient by adding pointer indirections.

current state of the art

Currently Zig has compile time ducktyping.
However, one can not easily restrict input to a certain class of inputs. This yields bad compile error messages and very bad readability as explained in the following:
An example: a func that takes some struct with method foo() on it and calls foo(). If you pass in a struct that does not have foo() you get an error, possible deep down the hierarchy which bubbles up out of some library. This error should be brought up at the immediate calling position where you passed your struct.
Even more importantly its bad for documentation because its not clear to the reader what kind of var that func takes. It is much better to express that it takes a struct that has a fucntion foo() by using interfaces.

explanation

A missconception is that interfaces have to happen at runtime and or involve some notion of vtables.
As proposed, interfaces are just compile time checks on a type.
These improve performance because methods are just like regular methods on structs, not fucntion pointers that require an additional lookup.

syntax for interfaces should clearly be

const some_interface = interface {
    fn foo () i32;
    some_int: i32;
}

fn some_func (i: some_interface) {
    i.foo ();
    // ....
}

You can pass any struct to some_func that has a method foo() on it.

---

To be discussed:

• a) interfaces can allow to specify member variable as well as functions
• b) interfaces can be used as a member variable that has a variable that has the inteface
• c) explicitly implement an interface, sometimes you want to make sure your custom_allocator actually implements the allocator interface, there can easily be added a small syntax to ensure this or a small hack like in golang using an anonymous variable, its not a big deal.

I think all those should be possible but i'd actually recommended to do a first implementation without those three because they can be added later without issues.

---

This proposal should go along with #1214 making inheritance obsolete by using clean composition.

Also see #1170 (comment) for extremly positive effects of this proposal.

---

---

There have been proposals for hacking interfaces using metaprogramming which would have bad consequences because error messages will suffer, everyone will roll their own incompatible imeplentation and as shown above interfaces offer an indespensible tool for structuring code.

If you just want to write c, you can ignore this proposal but your code will be harder to read for most people, harder to debug, refactor(see 2nd link) and possible inefficient.

thanks for your attention 👍

[BarabasGitHub]

b) interfaces can be used as a member variable that has a variable that has the interface

I don't get this. An interface isn't a concrete thing I'd say, so it doesn't make sense to have it as a member.

c) explicitly implement an interface, sometimes you want to make sure your custom_allocator actually implements the allocator interface, there can easily be added a small syntax to ensure this or a small hack like in golang using an anonymous variable, its not a big deal.

Maybe, although if the purpose it to make sure I'd say write a test that tests this. It might be good for documentation purposes though, but it can also add clutter.

[isaachier]

@BarabasGitHub you could embed a vtable which would just be a struct of function pointers. That is essentially what we have in Zig now. Then, with Plan 9 struct embedding, at least stdout.stream.print could be reduced to stdout.print.

I don't get this. An interface isn't a concrete thing I'd say, so it doesn't make sense to have it as a member.

it is difficult indeed because you may end up having some struct in place of that interface

const a = interface {}

const s = struct {
a_member : a;
}

some_s : s;
// ...
s.a_member.foo; // you never know if a actually has .foo so you would always have to assert on runtime 

this is not something very important and as said, it should be left out initially and only eventually added.

Maybe, although if the purpose it to make sure I'd say write a test that tests this. It might be good for documentation purposes though, but it can also add clutter.

yes, as said its a non issue, there are many ways to solve is and its not hard, pick your poison and just use one in the end

@isaachier

you could embed a vtable which would just be a struct of function pointers.

you would not need a vtable cause all functions, even the embedded ones would be known at compile time unless im terribly mistaken

this proposal is all about really not magical really straight forward compile time checking not any wizardry/ pointers involved

[isaachier]

Again, there is a fine line between type constraints and interfaces. Interfaces are runtime-specific. An interface allows me to load some blob into memory and know how to call a method because I know how to access the vtable. The compiler emits the code to make this function call without knowing the underlying type of the object. Imagine the following C++ code:

class Animal {
  public:
    virtual ~Animal() = default;

    virtual void eat() = 0;  // Pure virtual/abstract method
};

class Dog : public Animal {
    void eat() { /* some implementation here */ }
};

namespace {

void feedAnimal(Animal& animal)
{
    animal.eat();
}

}  // anonymous namespace

int main()
{
    Dog dog;
    feedAnimal(dog);
    return 0;
}

godbolt.org using clang-trunk emits this output (see more here: https://godbolt.org/g/2WNNBU):

...
(anonymous namespace)::feedAnimal(Animal&): # @(anonymous namespace)::feedAnimal(Animal&)
  push rbp
  mov rbp, rsp
  sub rsp, 16
  mov qword ptr [rbp - 8], rdi
  mov rdi, qword ptr [rbp - 8]
  mov rax, qword ptr [rdi]
  call qword ptr [rax + 16]  ; this line is calling a function pointer in the vtable
  add rsp, 16
  pop rbp
  ret
...

Again, there is a fine line between type constraints and interfaces. Interfaces are runtime-specific. An interface allows me to load some blob into memory and know how to call a method because I know how to access the vtable. The compiler emits the code to make this function call without knowing the underlying type of the object. Imagine the following C++ code:

this is a different example and does not apply to this proposal

in your case the issue is that, feedAnimal does not know which method it has to call because it does not know which type its passed. Is it a dog, cat .... its just any animal.

---

But with this proposal you know exactly what struct you pass and know all functions on that struct so there is no issue.
This again needs more thought once you allow member variables that have the type of an interface but we are not talking about this yet, that is not as important as the proposal itself.

---

can you provide the same example with the proposed interfaces and create a case where its not crystal clear what function to call at compile time? I can not.

[tgschultz]

Just for the sake of argument, you can do something like this with currently existing Zig:

fn ifaceAssert(x: var, comptime I: type) void {
    comptime T = @typeOf(x);

    //uses @typeInfo to compare I's members and defs to
    // T's, throwing a compileError if any part of I is missing
    // from T.
}

const BarInterface = struct {
    data: []u8,

    //for comparison purposes a parameter with type
    // of the interface is considered as "SelfType",
    // which is to say that it matches the target type
    // of the comparison.
    fn bar(self: BarInterface, usize, []const u8) void;
};

fn foo(x: var) void {
    ifaceAssert(x, BarInterface);

    x.bar(10, "ABCDEFGHIJ");
}

@tgschultz thanks for the concise example which is on point

The question is, why isn't it done this way in the std?

Maybe because its extremely tedious to type (and actually read as well) for something that should be strongly encouraged rather than made harder and thus discouraged?

For me this just shows how easy it would be to implement in the compiler and what a very small addition can bring as a huge benefit to all user facing code.

[tgschultz]

Well we didn't have @typeinfo until relatively recently, for one. But now that we do we've been working on std.meta and maybe something like this should be a part of it. That'd alleviate a lot of the typing hassle while still providing most of the benefit provided by handling the concept in the language itself. To me, that's a worthwhile tradeoff, others may legitimately disagree.

To me, that's a worthwhile tradeoff

a tradeoff between typing and then reading multiple times lots of boilerplate VS having one more keyword that is extremely unobtrusive?

I get that many just want good old c but good old c did not have any of this meta magic either and I prefer a clear syntax instead of dozen lines of meta programming unless I want to play games and feel creative which may be the case from time to time. There is its own reward in understanding some meta meta code after staring at it long enough.

One keyword more is certainly closer to c than typeof, typeinfo etc. etc. chained together in some artistic way.

[tgschultz]

If something like ifaceAssert were in the std lib, then it wouldn't be dozens of lines on the users end. Compare:

const some_interface = interface {
    fn foo () i32;
    some_int: i32;
}

fn some_func (i: some_interface) {
    i.foo ();
    // ....
}

to

const SomeInterface = struct {
    fn foo (SomeInterface) i32;
    some_int: i32,
};

fn someFunc (i: var) {
    std.meta.ifaceAssert(i, SomeInterface);
    i.foo ();
    // ....
}

[isaachier]

@monouser7dig I am saying this is precisely the problem with using the word interface in this proposal. Also, I'm not sure why the use of comptime type variables doesn't solve most issues for compile-time type constraints.

[isaachier]

OK thought this over and realize what you are asking for is along the lines of C++ concepts. Look at that and see if similar idea could be used in Zig.

Edit: here's the link: https://en.cppreference.com/w/cpp/language/constraints.

I am saying this is precisely the problem with using the word interface in this proposal.

quote: Interfaces / Traits (the terminology is left to the reader / implementer)

Not a huge fan of comparisons to cpp, I mean what @tgschultz outlined pretty precisely so don't think there is value in adding ambiguity.

@tgschultz I very much like your last example and would very much like to see this

In the beginning I mentioned the current Allocator struct as a bad example without yet providing a 100% coverage of what it achieves, namely default functions.

If you implement three basic functions you get the rest for free by calling parent functions by suing parentPointer.

This can be done with this proposal as well, but much easier for the reader and writer.
Every function that is implemented in terms of the basic allocator interface (which consists of those three functions) can be turnt into a free function that takes as first parameter a var and asserts that ist an allocator (see #1268 (comment) ) and then takes the usual arguments. It can then call/ get/ use the three basic allocator functions by using the ones provided by the struct that implements the allocator interface.
The only difference at call side is foo(some_struct, other_param1, other_param2) vs currently some_struct.foo(other_param1, other_param2) and there could be syntactic sugar to make both equivalent as its currently the case with struct methods already. (not sure this would work already in this exact case but its not a big deal anyway)

---

another gotcha for the implementation of this meta programming facility is:
Its important that this (#1268 (comment)) works with struct embedding (#1214) as well. Such that the interface can be satisfied by a struct that is embedded.

This must be rigid and not have weird edge cases but if people insist meta programming can solve this I'm curious to see.