Proposal: Interfaces

[BraedonWooding]

Currently duck typing is great, however there are a few issues with duck typing and these include the fact that the errors you get aren't always great, so I propose we add 'interfaces' which look very similar to structs however what they are meant for is as a supplied type in functions or wherever duck typing can be used.

I think an example is the best way to show it;

const IteratorInterface = interface {
    opt fn reset(self: &this) void; // Optional
    req fn next(self: &this) i32; // Required

    xor fn getFoo() i32, 
    fn getBoo() u8;
};

pub fn foo(comptime iterator: IteratorInterface) void {
    warn("{}", iterator.next());
    if (@interfaceHas(iterator, reset)) {
        iterator.reset();
    }

    if (@interfaceHas(iterator, getFoo)) {
        // Won't have 'getBoo'
    } else {
        // Has to have 'getBoo'
    }
}

Note: that the 'this' type has to be used but it isn't talking about the interface but whatever it is compared to.

As you can see it is just duck typing but the key difference is in the use of it, and in the compile time errors you get! If you call it with an iterator that doesn't have a 'next' function then the compiler will give you a nice error; "<STRUCT_NAME> struct is missing required function/s: 'fn next(self: &Self) i32'". Another nice thing about this system is that it is nicer with optional requirements.

You can't currently do this at all, however with the new @typeInfo it'll be possible to simulate this from what I can see, however in doing it, you end up with much uglier and obfuscated code than something like this;

Motivation

I've been building out a LINQ library in Zig (called Lazy, because well it is all about doing lazily executed queries on data structures, all around 'yield'ing getting values when you need them which remove the need for allocators completely in some cases and can provide a nice speed boost), and on of the annoyances was trying to get it to work with hash_maps and array lists using an .iterator that is provided by those things. Currently it isn't solvable to do a generic call like Lazy.init(myObj) and have it figure out what to do since it can't detect if functions exist, having something like above, would simplify a lot of my structures and would make errors a whole lot nicer.

On a side note if you are interested in the idea of the library I've got a simple example version on my github here. 😄.

[alexnask]

You can't currently do this at all, however with the new @typeInfo it'll be possible to simulate this from what I can see, however in doing it, you end up with much uglier and obfuscated code than something like this;

My intention is to write a std.meta package that will make things a lot smoother (functions like has_method(), has_self_method(), etc. etc.).

Personally I'm not too keen on this proposal for two reasons:

• The name (interfaces) is usually associated with runtime polymorphism (ofc it could be renamed to trait, concept or w.e.)
• This could be written in userspace

Btw, for something quite similar (an interface implementation but in the runtime polymorphism sense), this is a proof of concept: https://gist.github.com/alexnask/1d39fbc01b42ce2b5b628828b6d1fb46

[BraedonWooding]

@alexnask, good work on your PR by the way; really what I needed for something I was doing :).

Yeh I wasn't meaning for it to have runtime polymorphism, more like a way to have certain traits enforced onto your types, however I think handling it is much easier with the whole 'has_method' thing and so on :). So really this proposal falls apart with that idea of those functions existing.

[alexnask]

@BraedonWooding
Right, a rough sketch of how this could be implemented in userspace is:

pub const Concept = struct {
    pub const MethodType = enum {
        Self,
        ConstSelf,
        Static,
        Any,
    };

    pub const Rule = struct {
        method_type: MethodType,
        name: []const u8,
        fn_type: type,
        is_required: bool,
    };

    rules: []Rule,
};

const IteratorConcept = Concept {.rules = []Rule {
    // Note how we ignore the self argument in the fn_type.
    Rule { .method_type=Concept.MethodType.Self, .name="reset", .fn_type=fn()void, .is_required=false },
    Rule { .method_type=Concept.MethodType.Self, .name="next", .fn_type=fn()i32, .is_required=true },
}};

pub fn matches_concept(comptime T: type, comptime concept: Concept) bool;

// Could use the std.meta functions instead, but this also checks the type's method matches the concept's
pub fn concept_has(comptime T: type, comptime concept: Concept, comptime name: []const u8) bool;

[bheads]

Other duck typing tools could also solve the problem. One is a test to see if a give bit of code compiles and the other is a conditional on the function signature:

pub fn foo(comptime T: type, T: a) int if (@compiles( a.bar() )) {
  return a.bar();
}

With this you can build a concept test:

pub fn isIterator(comptime T: type) bool {
  // A more detailed test would look at the return types...
   return @compiles({x: T; x.reset();}) and @compiles({x : T;  x.next();});
}

pub fn foo(comptime T: type, T: iter) void  if(isIterator(T)) {
  while(iter) |val| {
   ....
  }
}

[BraedonWooding]

@compiles seems to ambiguous for my taste; and from a compiler standpoint isn't particularly feasible. Also that second code example wouldn't work at all you would want something like;

pub fn foo(comptime T: type, T: iter) if(isIterator(T)) void else unreachable {

You could put a compile error in the place of unreachable too (well rather you should).

Or rather the common pattern is something like;

pub fn foo(comptime T: type, T: iter) void {
    if (!isIterator()) {
        @compileError("Class supplied does not have a '.reset' and '.next' method");
    }
    while (iter.next()) |val| {
        ....
    }
    ....
}

[bheads]

The idea of the conditional test on the function signature is to control the function matching. Basicly if T is not an iterater the function doesn't match nor compile, thus no function foo that takes an iterator.

This opens up generic function overloading. I am not 100 on this syntax just the idea.

fn foo(T:type) void  if(isThing(T)) {}

fn foo(T:type) void  if(other thing(T)) {}

The @compiles is a very generic solution to test code constructs, ie covers the cases not covered by other comptime functions. typeOf and memberOf and others would probably be strong tests used.

[alexnask]

@bheads

I love Dlang's compiles trait, however as far as I'm aware there are no plans for zig functions to directly read or generate bits of AST/unevaluated expressions.

You should take a look at @typeinfo, it gives us access to all the information we need to create such tests and covers 99% of the cases where @compiles would be useful.

Ofc, there still needs to be a nice wrapper over @typeinfo.
My plan is to start writing the std.meta package this weekend, as well as some basic @reify/@createtype functionality.

std.meta will provide functions like has_field, has_child, has_method, has_self_method, is_slice_like, etc.

[bheads]

A std.meta package would be great, but what about conditional compilation on function signature? It is a nice was to solve concepts without a clunky library solution or shoehorning it into the language.

Something like this should be optional to use, enforced by the compiler, and easy to understand. This is one of the few things I think D got right. I have found suck typing and concepts are a better solution then interface. (I code a lot of "Enterprise" Java for work.. )

I am looking for a D replacement and hope zig is it, but there are a few language features I don't want to lose, strong generics/meta programming and concepts is one of them.

[Hejsil]

@bheads By conditional compilation on function signature do you mean this example from above?:

fn foo(T:type) void  if(isThing(T)) {}

fn foo(T:type) void  if(other thing(T)) {}

If so, then I don't quite see the benefit.
This code has, semantically, everything that the above have:

fn foo(comptime T: type) void {
    if (isThing(T)) {}
    else if (otherThing(T)) {}
    else { @compilerError("Some good error message"); }
}

With Zig's lazy analysis, only the block that is true is analyzed and compiled. The others are ignored by the compiler.

[bheads]

With this function

fn foo(comptime T: type) void {
    if (isThing(T)) {}
    else if (otherThing(T)) {}
    else { @compilerError("Some good error message"); }
}

You can no longer overload it for new types of T. If foo is in the std library then a user can no longer overload it. Also what happens when there are 3, 4, 10 different cases to handle? Functions like this can be come very large and unruly.

but with this style:

// Std lib functions for foo
fn foo(T:type) void  if(isThing(T)) {}
fn foo(T:type) void  if(otherThing(T)) {}

a user or other lib can still add overloads, and the function only handles a single type case.

// mylib.zig foo for unicorns
fn foo(T:type) void  if(isUnicorn(T)) {}

[BraedonWooding]

Function overloads aren't a thing in Zig (and editing an already built external API like std from your program is typically seen as bad practice as it invites all kind of bugs). I don't see them ever becoming a thing. I don't see how there is any difference between the two code examples you gave sorry. To me they have the same noise, there are other ways to accomplish the task, such as using structs, other functions to handle cases and so on; for example;

fn foo(comptime T: type) void {
    switch (getHandlingForThing(T)) {
        Cases.IsThing => DoThing,
        Cases.OtherThing => OtherThing;
        else => @compileError("");
    }
}

Looks quite fine to me, you could even switch on the TypeID yourself if that's all you care about, maybe have a look at some of the math functions to see this stuff in action.

Also what happens when there are 3, 4, 10 different cases to handle? Functions like this can be come very large and unruly.

What's a use case for 10 different cases? 3 or 4 would be the maximum, 5/6 would truly be rare, anything over that I couldn't see it being the best solution and that using another solution would be better.

As with the other issue we need to see some 'real world cases', i.e. give us an example where it is needed (I struggle with this sometimes too, you get a really good idea but sadly it isn't really needed; despite it being a really good idea!!!). A good example for what we are looking for would be the following;

Why I think we need switch cases in Zig

Switch cases are used universally across languages, with people often simulating them in languages like Python where they don't come 'naturally', they are very useful for things like emulators and drivers something that as low level as Zig should support; furthermore they also provide superior code to a series of if statements if the amount of cases is < 100 and are all sequential as it produces a lookup table, meaning that switching on enums often is much more efficient then checking them one by one.

Normally you would also add an example outline of the syntax, and some links to the claims you made (the main one I made was the whole lookup thing, I'm not 100% sure the numbers are correct but for the sake of acting as an example, it is fine, however if I was submitting a proposal I would have to do my research to make sure my facts are correct; otherwise it reduces your credibility). Also giving a link to a github page or a gitlab, or really any project that uses your idea for example in this case a switch statement (and using it is the best solution) really helps.

Hopefully this helps :).

[bheads]

No function overloading... thats archaic. Is there any posts on why not? I also noticed there are no default parameters.

[Hejsil]

@bheads All rejected issues are here. I can't find a proposal specificly for function overloading, but related are #871, #427 and #148. For default parameters we have #484.

I recommend reading through the rejected proposals. It'll give you an idea as to what kind of language Zig is. Just remember, things are rejected for good reason, and the userbase of Zig values the way Zig does things.

[BraedonWooding]

@bheads 'archaic' is a point of contention; Zig has a few similarities to Go and not having function overloading is one of them, it is an archaic view like header files; there are valid reasons.

From what I've gathered and my personal experience generally it seems that function overloading removes context in a lot of cases and generally when you have type ducking you cover the cases where it is very much needed; and in the other cases many people would say not to use it.

Here are a few examples;

• addEntity() may have overload for adding a player through their name like addEntity("Mike"), but that removes context and really should be addPlayerEntity("Mike") or maybe addEntity(Entity.Player, "Mike") again, I would prefer the addPlayerEntity but that is definitely a subjective opinion.
• add(int, int) and add(float, float) in Zig can just be done through a add(Type: type, Type, Type), such that you call it like add(i32, 5, 9), you could also implement it like add(a: var, b: @typeOf(a)) so you can call it like add(5, 9) and tada it works; you could also just add them together and wouldn't have to condition them into float and int camps; could also bunch all the ints into a single typeID and same with floats allowing you to just check two states rather than multiple giving a compile error if type is invalid.

Default parameters is something that is a something you often get when having function overloads, I quite like them but again they remove information; those links that Hejsil (thanks) gave are really good to see some good counter arguments to that. I do potentially see them in the future though I don't what form they'll be in.

[bheads]

Sorry if I come off strong or offensive, not my intentions at all. I just had nightmares of C and Java Enterprise code I deal with day to day that would be solved with function overloads and optional params.
Nothing like a Java interface that has 20+ overloads just to deal with optional params...

But I think duck typing with good comptime reflection, a std.meta library, along with guidelines and examples would remove the need for an interface in the language or STD lib.

[binary132]

I like the idea of enforcing type constraints, but I really think stronger wording than "interface" or "trait" should be used, because there is a ton of overloaded language around this stuff. "interface" strictly means runtime dynamic types in some languages, for example. "trait" is even worse, because it can mean runtime OR compile-time dynamic type in Rust. The C++ term "concept" is pretty good because it is quite distinct and different, and well-specified, for example.

I also think one of the things Go gets right about this is that the implementing type doesn't need to explicitly declare that it implements some "trait" or "interface"; this responsibility is in the caller, instead. So I could define my own interface that some stdlib type happens to implement, and use that type in my code, without modifying the stdlib type. This is the benefit of "duck typing".

[BraedonWooding]

I don't think this is needed anymore, I agree @binary132 but with the latest changes to reflection it is quite easy to get this kind of behaviour :). Closing issue

[ghost]

but with the latest changes to reflection it is quite easy to get this kind of behaviour :)

Is now everyone expected to roll his own interface implementation? I think this issue really should be solved uniformly otherwise this is just a big mess and I do not think basic features should be bolted onto zig with reflection hacks 👀

[0joshuaolson1]

@monouser7dig How would an std.meta be a hack? It's just userspace, like other 'basic' abstractions that might not get consensus to be in Zig.

[ghost]

If it's not in zig, everyone will do it differently and when reading someone else code you/ (at least I) get confused very easily.

[isaachier]

I think reflection using indicates runtime reflection, but I imagine you are referring to the compile-time type introspection offered in Zig. Can you please provide an example @BraedonWooding.