Implementing Generic Concepts on Function Declarations

AndrewCodeDev · August 13, 2023, 4:35am

– edited – See below (post 4) for an updated version of this using function prototyping –

I’ve was thinking about how to implement more transparent constraints for anytype parameters - I was thinking about ways to expose this as apart of a function declarations. So I came up with an example to demonstrate something using conditional statements in the return type.

Basically, the first argument is evaluated as the constraint, and the second argument is evaluated as the result type. This has some similarity to “Enable If” in C++…

const std = @import("std");

fn RequiresInteger(comptime constraint: type, comptime result: type) type {    
    return switch (@typeInfo(constraint)) {
        .Int => { 
            return result;
        },
        else => { 
            @compileError("Constraint: must be integer type.");
        }
    };
}

fn genericFunction(x: anytype) RequiresInteger(@TypeOf(x), bool) {
    return true;
}

test "Successful Requirement" {
    const x: usize = 0;
    std.debug.assert(genericFunction(x));
}

test "Failed Requirement" {
    const x: struct { } = undefined;
    std.debug.assert(genericFunction(x));
}

Now, this is a very simple example, but the Requires function can be arbitrarily more complicated. You can check for all kinds of things with Zig’s reflection capabilities.

The value of this is that it moves the requirements out of the function’s body and into the declaration. ZLS perfectly displays the full declaration with the requirement clause as the return, so it’s quite friendly to language tools - when typing genericFunction(), here is what ZLS shows:

fn genericFunction(x: anytype) RequiresInteger(@TypeOf(x), bool)

The error message is quite nice too:

main.zig:9:13: error: Constraint: must be integer type.
            @compileError("Constraint: must be integer type.");
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main.zig:14:47: note: called from here
fn genericFunction(x: anytype) RequiresInteger(@TypeOf(x), bool) {

Thoughts?

IntegratedQuantum · August 13, 2023, 9:08am

That’s a really cool idea.

However I think it gets a bit unreadable in more complicated cases. Let’s say we want a struct with a few functions.
I think in this case it gets a bit convoluted and it’s hard to find the return type:

RequiresStructWithFunctions(.{.functionA, .functionB}, .{fn(@TypeOf(x)) bool, fn(@TypeOf(x)) usize}, @TypeOf(x), bool)

Would it be better if the return type was in the beginning? Maybe a structure like this would be more readable:

Returns(bool, requiresStructWithFunctions(.{.functionA, .functionB}, .{fn(@TypeOf(x)) bool, fn(@TypeOf(x)) usize}, @TypeOf(x)))

Where Returns would be:

fn Return(T: type, _: void) type {
    return T;
}

motjuste · August 13, 2023, 11:59am

I was just drafting a post (my first here) asking something about constraining what shape of arrays are accepted by a function. Here’s an sample code for background (any improvements to it are very welcome):

// What can be put here to indicate [_][2] array is expected?
//            |
//            |
//           \|/
fn doIt(arr: anytype) @TypeOf(arr[0][0]) {
    const T = @TypeOf(arr[0][0]);
    var res: T = 0.0;
    for (arr) |xy| {
        res += xy[0] + xy[1];
    }
    return res / @as(T, arr.len);
}

const expect = @import("std").testing.expect;

test "averaging" {
    const arr = [_][2]f32{
        [_]f32{ 0, 0 },
        [_]f32{ 1, 2 },
        [_]f32{ 2, 4 },
        [_]f32{ 3, 6 },
        [_]f32{ 4, 8 },
    };

    try expect(doIt(arr) == 6);
    try expect(doIt(&arr) == 6);
}

`anytype` function args

I am very new to Zig and (coming from Python, Java, Rust, etc.) functions accepting anytype are not very informative in the small completion pop-ups in my editor. Concepts feel like the right idea, but if they are going to constrain the accepted args, shouldn’t they be written where the args’ type is specified, instead of where the return type is specified?

AndrewCodeDev · August 13, 2023, 1:25pm

I’m glad you’re seeing that there’s something here worth looking at - I’m definitely open to moving things around because I can agree that it’s hard to see the return type in the example you provided. In fact, your example is very similar to the next idea I had which allows for concept composition:

First, we can declare a function prototype like so. In this case, it’s just a high-level wrapper for the return type and preconditions…

fn Prototype(comptime result: type, comptime constraint: bool) type {
    if (!constraint){ 
        @compileError("Failed function prototype constraints.");
    }
    return result;
}

This function isn’t strictly necessary but for the sake of clarity here it is…

fn Returns(comptime result: type) type {
    return result;
}

We can make two different concepts here…

fn isInteger(comptime T: type) bool {    
    return switch (@typeInfo(T)) {
        .Int => {  return true; }, else => {  return false; }
    };
}

fn isStruct(comptime T: type) bool {    
    return switch (@typeInfo(T)) {
        .Struct => {  return true; }, else => {  return false; }
    };
}

And all of that leads up to function prototyping that allows for concept composition like so…

fn genericFunction(x: anytype) Prototype(
    Returns(bool), isInteger(@TypeOf(x)) or isStruct(@TypeOf(x))
){
    return true;
}

I think there’s something here if we can keep work-shopping it!

IntegratedQuantum · August 13, 2023, 1:53pm

Yeah, that one is even better and more flexible.
Sadly this however means we loose information about which of the conditions failed.
That might be fine though.

AndrewCodeDev · August 13, 2023, 1:56pm

There are ways to do this in canonical Zig that show up in the standard library quite often. One way to do it is to use a slice for the first argument instead of a fixed size array and then just have another comptime parameter as the type. If you want more feedback on how to do it that way, I think opening a new thread would be the best way to get feedback on your specific issue.

Going off of the topic of this thread, we could prototype your function this way:

fn Prototype(comptime result: type, comptime constraint: bool) type {
    if (!constraint){ 
        @compileError("Failed function prototype constraints.");
    }
    return result;
}

fn isPair(comptime T: type) bool {
    return switch (@typeInfo(T)) {
        .Array => |arr| {
            return (arr.len == 2);
        }, 
        else => return false
    };
}

fn doIt(arr: anytype) Prototype(
    @TypeOf(arr[0][0]), isPair(@TypeOf(arr[0]))
){
    const T = @TypeOf(arr[0][0]);
    var res: T = 0.0;
    for (arr) |xy| {
        res += xy[0] + xy[1];
    }
    return res / @as(T, arr.len);
}

AndrewCodeDev · August 13, 2023, 2:07pm

Yeah I was thinking about that. You know, we could have a mix of hard and soft constraints.

A hard constraint is one that raises a compile error with a direct message or returns true. That way, we could have messages if we really wanted to enforce something specific.

Otherwise, a soft constraint could be one that just returns bool without raising a compile error. This would allow for further concept composition to occur and would not necessarily stop the compilation if the concept isn’t fulfilled.

That way, you could easily have a mix of both.

IntegratedQuantum · August 13, 2023, 2:12pm

But wouldn’t that add visual noise to the code, because I assume you’d probably need both variants for many functions, leading to isIntegerSoft and isIntegerHard or something like that.
Additionally I think it would cause confusion, for example when you accidently use isIntegerHard(...) or isStructHard(...) instead of the soft variants you will get a compiler error.

AndrewCodeDev · August 13, 2023, 2:18pm

I mean, it might - the thing is, OR statements already kind of do what I was referring to here because it is a form of a soft constraint. Likewise, nothing stops someone from just raising a compile error wherever they’d like, so if they really wanted to it’s obviously not prohibited lol.

I’d like to see some more examples of where the readability becomes a bigger problem. Because the composition can occur internally to a function as well… like in the case I wrote above, you could just have:

isInteger(T) or isStruct(T) -> isIntegerOrStruct(T)

That way, embedded statements can be more easily addressed and named.

IntegratedQuantum · August 13, 2023, 2:31pm

nothing stops someone from just raising a compile error

Yeah but it is about convention. Like how do I know which function is throwing a compile-error as a hard constraint? And which function can be composed with others?
Let’s say I have a function

fn doSomething(x: anytype) Prototype(
    Returns(void), isInteger(@TypeOf(x))
) {...}

And want to modify it, so it also accepts floats:

fn doSomething(x: anytype) Prototype(
    Returns(void), isInteger(@TypeOf(x) or isFloat(@TypeOf(x))
) {...}

Then boom, compiler error because isInteger was a hard constraint.

AndrewCodeDev · August 13, 2023, 2:36pm

Right, I’m agreeing with you. I could have been more clear about that

In a sense, given a function prototype, if we only have one constraint, that constraint is a hard constraint. So for instance:

Prototype(…, isFloat(T)) → isFloat is a hard constraint because it must be satisfied.

Prototype(…, isFloat(T) or isInteger(T)) → isFloat is a soft constraint because it is optional.

So yeah, I’d agree with your point about keeping compile errors out of the concepts by convention because it raises the issue you’re referring to.

– edited for further clarification –

Regarding readability, I mean given what you have already brought up, I just want to see more examples of this in action to actually see the readability. I think your first example was good regarding the struct with functions and I’d like to take a crack at solving some more of these to see if this idea looks good in practice.

IntegratedQuantum · August 13, 2023, 3:53pm

I just want to see more examples of this in action

I can try to find some examples of using anytype throughout my code.

I sometimes have cases where the return type already implicitly checks the restrictions. For example this vector dot-product:

pub fn dot(self: anytype, other: @TypeOf(self)) @typeInfo(@TypeOf(self)).Vector.child {
	return @reduce(.Add, self*other);
}

So the Prototype pattern would probably decrease readability here.

This one is a bit fancy, essentially it accounts compares to a pointer that contains a .pos field of matching type, but that pointer may be optional, so this is implemented recursively:

pub fn equals(self: ChunkPosition, other: anytype) bool {
	if(@typeInfo(@TypeOf(other)) == .Optional) {
		if(other) |notNull| {
			return self.equals(notNull);
		}
		return false;
	} else if(@typeInfo(@TypeOf(other)) == .Pointer) {
		return std.meta.eql(self, other.pos); // other must have a .pos field.
	} else @compileError("Unsupported");
}

Probably something like that, but that doesn’t quite reflect the recursive nature:

pub fn equals(self: ChunkPosition, other: anytype) Prototype(
    Returns(bool),
    isOptional(@TypeOf(other))
    or (
        isPointer(@TypeOf(other))
        and hasFieldOfType(@TypeOf(other), .pos, ChunkPosition)
    )
) {

It is not obvious from the call signature that the optional would need to be an optional pointer with the given struct field.

These are all the problematic cases I could find in my code. Apart from that I usually just have simple requirements, like integers or tuples.
In one case(a json parser) I have a lot of possible types, but that would just be some work writing down all the possible cases.
One case that might be more complicated is the use of reader/writer, but I think a isReader/isWriter function would make sense there.

AndrewCodeDev · August 13, 2023, 8:00pm

Thanks for digging these up!

Yes, I think your “isReader/isWriter” point is spot on. I can picture this being more useful for high-level interfaces, such as isForwardIterator, etc…

One example I have is for implementing something like the strategy/factory pattern where we inject dependencies into a builder that returns a struct with our desired components. Likewise, iterator interfaces and general compound types that need to have several fields in one spot would help. I also think this is helpful in cases where *anyopaque member variables are involved as well. Since we’re losing type information, we can add constraints to the interface if we so choose.

In terms of this:

pub fn dot(self: anytype, other: @TypeOf(self)) @typeInfo(@TypeOf(self)).Vector.child {
	return @reduce(.Add, self*other);
}

That return type is quite gnarly as is, so I don’t think much besides a comptime helper function to unpack that would be helpful. So for instance:

fn ElementType(comptime T: type) type {
    return @typeInfo(@TypeOf(self)).Vector.child
}

But that essentially is its own constraint. It has to be a vector for that to even work so it’s probably not super useful here.

In your second example of equals, the only thing that comes to mind right now is the following…

fn hasPointer(comptime T: type) bool {
    return switch (@typeInfo(T)) {
        .Optional => |opt| { 
            return hasPointer(opt.child);
        },
        .Pointer => { 
            return true;
        },
        else => false        
    };
}

And in the .Pointer segment, you could add your concepts to form the pointer constraint. Of course, we’d want to rename that concept at that point, but the general point is still there.

– edited to finish the example –

So for the equals concept, it could be like this…

fn hasPointerToChunkPosition(comptime T: type) bool {
    return switch (@typeInfo(T)) {
        .Optional => |opt| { 
            return hasPointerToChunkPosition(opt.child);
        },
        .Pointer => |ptr| { 
            return hasFieldOfType(ptr.child, .pos, ChunkPosition);
        },
        else => false        
    };
}

AndrewCodeDev · September 21, 2023, 8:04am

I wanted to post a link to a project that does something similar to this idea and is much more fleshed out.

I was not aware of this library at the time of making this post. It takes a different syntactical approach but has some interesting features. Check it out if you are interested in this stuff!

booniepepper · October 4, 2023, 10:05pm

This is blowing my mind

permutationlock · October 5, 2023, 8:25pm

I made something similar recently. I didn’t end up putting the concept/trait requirements in the function declaration, but it would be interesting to see if there is a way to do it that is still readable.

AndrewCodeDev · October 5, 2023, 11:02pm

@permutationlock, thanks for sharing your work!

This will be a long response, but here we go…

Readability is both the cause and the requirement for this issue. Fundamentally, anytype creates an opaque interface at the declaration level - an LSP that shows you function declarations cannot give you any more information beyond “it’s a type”.

This has a long history outside of Zig - a famous example from C++ is:

template<typename T, typename R> R foo(T&& x);

And, I would argue, this is only getting worse. From cppreference, this is a 2023 definition of std::optional’s transform: std::optional<T>::transform - cppreference.com

template<class F> constexpr auto transform(F&& f) &;

Now, they have a mechanism with templates called “terse syntax” with auto which was a step in the right direction:

void foo(concept auto x);

At least now, you could tell that x needs to satisfy the concept. This is very helpful because an LSP will show you this at the call site as you’re typing.

I had a great conversation with @booniepepper yesterday and we drafted a small (but useful) tweak that got added to the 1.0 milestones yesterday to help the compiler print more helpful invocation messages (thank you @booniepepper for the example that made it into the issue): Provide full function invocation during comptime. · Issue #17402 · ziglang/zig · GitHub

We talked about what is the “scope” of the problem we’re trying to solve. Fundamentally, the idea behind explicit constraint at the call site would hopefully mean that we get less compile errors in general because the programmer knows what should go into a function in the first place. In other words, the compile error itself isn’t my explicit target.

Another benefit is of course avoiding a world where the only indicator is implicit duck-typing (if you have a variable named count, we’ll just go ahead and use it). Ironically, that’s how many of the constraints still work - we just put it upfront so you can read it in one place.

“Announce that a duck is required and you’ll have less compile errors when a duck shows up.”
~ Lao Tzu (probably)

The issue I am interested in is on first contact - the first time I read a function declaration, do I know what this thing needs? This helps greatly with documentation - if I see something requires a “readable” object, then I can go lookup what constitutes readable.

Now, that said, I don’t think people want tremendous boilerplate to make sure you have a field called “my_int” in your struct, so it has to be manageable. Furthermore, as good at generics as Zig is, I don’t think generics is actually the heart of Zig - I think being a sensible C replacement is more inline with the goals and generics happen to be apart of that strategy.

Here are some related issues that are still open.

github.com/ziglang/zig

replace anytype

opened 02:42AM - 19 Sep 23 UTC

the-argus

proposal

**EDIT**: this issue is about both `anytype` and `comptime T: type`. All generic…s in zig, and how the types are constrained. for the most part, when I say `anytype`, just think "generics". `anytype` is a tool to defer all type logic into the function, where it can be dealt with imperatively at compile time. The result is a much poorer experience with language servers and poor ordering of information: the type constraints of the arguments of a function are the *first* thing you want to know. And yet `anytype` leaves them for later. The frustration of wanting to know what a function does and being greeted with `args: anytype` is what this issue is about. It sucks, and I know zig can do better. I'm going to try to summarize some previous issues on the subject, and offer some suggestions/proposals, but I don't want this issue to be closed if a suggestion is rejected, because the point of this issue is discussion, not proposal. If people like the idea then someone can make another issue marked as proposal. This issue will be closed if it's deemed not an issue but a feature, or if all solutions are out of scope. ### Example <details> <summary>Bad example which was originally in the issue</summary> `std.Build.dependency` is a nightmare. The function signature is `pub fn dependency(b: *Build, name: []const u8, args: anytype) *Dependency` and it takes three go-to-definitions to eventually arrive at `std.Build.applyArgs` where we can actually learn what `args` does. There are no documentation comments above any of these stdlib functions. Perhaps this could be solved by using an options struct of some kind. But nonetheless `anytype` is what got used and it's a problem that zig made it available for use in place of other options. Ideally, we'd like some sort of annotation in the function signature of `dependency` which makes it clear that `args` should contain a target and user input options. And give a helpful error message when it doesn't, checking at the call site of `dependency` instead of three functions down in `applyArgs`. </details> **EDIT**: the above example is a bad one, as pointed out [here](https://github.com/ziglang/zig/issues/17198#issuecomment-1725932228). Consider instead this snippet from the HashMap implementation: ```zig // If you get a compile error on this line, it means that your generic eql // function is invalid for these parameters. const eql = ctx.eql(key, test_key.*); ``` Where `ctx` is a generic type. This constraint is quite difficult to find if you don't find it the hard way, as it is buried in the private API of the HashMap. I think the use of `anytype` in the HashMap implementation is smart but it suffers in readability because there is no separation between comptime type validation logic and runtime logic (the former of which is much more important when learning the API). I think the most conservative solution to this problem would be if zig had some way of annotating a block as "for the type validation logic". Then some comptime asserts with nice error messages or comments could replace the example seen above. ### Precedent First, let's take a look at an existing solution, [Zig compile-time contracts](https://github.com/yrashk/zig-ctc). We know type constraints can be accomplished in the language already (and that's part of why a proposed solution needs to be really good) so it's worth looking at how it would be implemented given the status quo now. A sample from zig-ctc readme: ```zig fn signature_contract(t: anytype) contracts.RequiresAndReturns( contracts.is(@TypeOf(t), u8), void, ) {} ``` Compile time logic has to be inserted as a weird wrapper function around the return type. This could be helped a bit with `infer T` from #9260, but it still ends up pretty weird to read. This feels like something that should be a native language feature. It could be a stdlib feature instead, and maybe it should be. In #1669, a highly related issue, a user proposed [using comptime functions which return bool as types](https://github.com/ziglang/zig/issues/1669#issuecomment-481531875). It's readable, offers a nice experience to a user with an editor (they go-to-definition on the type, see instead it's a function, read the logic). Maybe not so nice for someone reading the code on a webpage. And, if #9260 were to be added to the language, we could remove the implicit function call and get the type of the thing in scope of the function signature: ```zig // some hypothetical function which takes a slice of types and an input type to compare against const oneOf = @import("std").meta.traits.oneOf; fn doSomethingWithAStringAndANumber(str: []u8, n: oneOf(&.{u8, u16}), infer T) void { // do something with n. it is a u8 or a u16! } ``` An improvement which I think is worth considering, in the spirit of rethinking these old, still relevant issues. But it doesn't solve the real problem, as we'll see in a moment. Another, extremely related proposal is #6615, which proposed something like this: ```zig fn Constraint(comptime T: type, predicate: fn (type) bool) type { if (!comptime predicate(T)) @compileError("wrong type"); return T; } fn write2(w: Constraint(@TypeOf(w), isWriter), data: []const u8) void { w.write(data); } ``` Additionally there were #7232 and #8008 (the latter of which was quite well thought out, proposing an `@trait` builtin. However. *all* these proposals were ultimately rejected: >There are a lot of problems with generic code. Generic code is harder to read, reason about, and optimize than code using concrete types. Even if it compiles successfully for one type, you may see errors only later when a user passes a different type. Generic code with type validation code has an even worse problem - the validation code has to match with the implementation when it changes, and there’s no way to validate that. So the position of Zig is that code using concrete types should be the primary focus and use case of the language, and we shouldn’t introduce extra complexity to make generics easier unless it provides new tools to solve these problems. Here we come to understand that Zig's fundamental focus on clarity conflicts with generics, not that there is some problem with the proposal, really. I said the earlier example of zig-ctc felt like "should be a native language feature." I thought "hey, with some added features to Zig, this could be much more readable, and maybe also in the stdlib." But it's clear now that the zig maintainers don't want ~~to solve that problem in the compiler~~ to have to add a bunch of complexity to zig only to get a slightly more readable version of the exact same functionality. However, `anytype` is still in the language and it still is used for things other than anonymous tuples and it *still sucks*. ### Distinct types offer a partial solution A big part of the goal here is just to provide more readable function signatures. Yes, it would be nice to do checking in the function signature, but maybe it's enough to just provide aliases for anytype? Like a slightly better doc comment. Maybe `anytype` could be replaced by something like `anontuple` and then only allow `anytype` when defining type aliases. Consider #5132 (typedef for zig) and #1595 (distinct types). ### Do something! `anytype` is a problem when used for anything other than anonymous tuples in string formatting. Is the best answer the zig language can give doc comments? We need to come up with some functionality which actually improves the experience of writing type-constrained generic code. Something that solves problems like the type checking code buried in `applyArgs`. ### Conclusion/Suggestion It doesn't make sense to say "generic code is bad, its hard to reason about, so we will not add facilities to make it easier because we don't want to encourage its use" when `anytype` still exists and still gets used. It seems to me that people would much rather write generic code with bad facilities like `anytype` and deferred type-constraining logic than maintain multiple well-tested but highly duplicated implementations of the same thing. Anything short of removing `comptime T: type` and `anytype` seems unable to stop this. Maybe the reasons we have for `anytype` being bad are enough to warrant reconsidering the previously closed issues like #1669? The fact that constraints on `anytype` are evaluated later, and not at the function where they're passed in, leads to confusing error messages. Additionally, it makes the function signature harder to read, and obfuscates information from tooling like ZLS. My only original suggestion is that Zig could automatically generate tests for functions with `anytype` or `comptime T: type` or equivalent. These tests would only test compilation of the function with all types, not actual functionality. It would require some new builtin `@constrainedTypeCompileError` or something along those lines, to skip tests for types you know shouldn't work with the function. Doing such an out-of-language solution means sort of giving up and saying "there's no way to make a language with maintainable generic code, so let's just test most of the possible inputs to these bad functions." I am hoping that someone else can come up with something better.

github.com/ziglang/zig

Proposal to improve the ergonomics and precision of type inference in generic functions

opened 12:37PM - 28 Jun 21 UTC

zzyxyzz

proposal

## Problem Generic functions, as currently supported in Zig have the form ``…`zig fn eql(x: anytype, y: @TypeOf(x)) bool { return x == y; } ``` This works well enough in general, but also has some problems and limitations: ### 1. Aesthetics Besides the controversial keyword (#5893), the `@TypeOf` pattern is a bit of a hack, even though everybody is used to it by now. It somewhat obscures the fact that `eql` takes two arguments of the same type. It also leads to unnecessary verbosity in some cases: ```zig fn foo(x: anytype, y: @TypeOf(x)) Container(@TypeOf(x)) { const T = @TypeOf(x); ... } ``` ### 2. Type signatures The type of a simple function like `same(x: i32, y: i32) bool {...}`, is `fn(i32, i32) bool`. For the generic function `eql`, the *intended* type is something like `fn<T>(T,T) bool`. But the actual type inferred by the compiler seems to be `fn(anytype,anytype) anytype`. In my limited testing, I found that the compiler essentially considers all generic and parametric functions to have the same type. Only the number of arguments is checked. E.g., the following code compiles: ```zig const eq: fn(anytype, f32) i32 = eql; // should have failed assert(eq(1, 1)); ``` It seems that the type check automatically simplifies to `const eq: any_generic_function = eql;`, which then succeeds. Maybe this is a limitation of the compiler that can be fixed independently, but then only in part. For example, the fact that both arguments of `eql` should have the same type is simply not expressible in the current system, since parameter names are not part of the type: `fn(anytype, @TypeOf(?)) bool`. This state of affairs reduces the precision of type checks, and also discards valuable information that could be used by documentation generators, mataprogrammed interfaces and error messages. ### 3. Order dependence Another minor nit is that generic functions constrain the order of function parameters in some cases. This, for example, is not possible: ```zig fn find(haystack: ArrayList(@TypeOf(needle)), needle: anytype) usize {...} // error ``` The arguments need to be the other way round, although logically they can be in any order. This is an arbitrary, albeit minor, limitation. ## Proposed solution Change the `fn(x: anytype)` syntax to `fn(x: infer T)`, which infers the type of `x` and binds it to `T`. Example: ```zig // before: fn eql(x: anytype, y: @TypeOf(x)) bool {...} // after: fn eql(x: infer T, y: T) bool {...} // before: fn find(needle: anytype, haystack: ArrayList(@TypeOf(needle))) usize {...} // after: fn find(needle: infer T, haystack: ArrayList(T)) usize {...} ``` This makes the intent much clearer, IMO. More importantly, the naming of inferred types allows us to talk about the types of generic functions with much greater precision: ```zig // before: eql: fn(anytype, anytype) anytype // after: eql: fn(infer T, T) bool // before: find: fn(anytype, anytype) anytype // after: find: fn(infer T, ArrayList(T)) usize ``` This forms the bare bones of the proposal, but there are additional possibilities that could be easily layered on top of it: ```zig // Make type name optional: fn wrapper(x: infer _) void { other_generic_function(x, 0); } // Unrestrict order of inferred parameters: fn find(haystack: ArrayList(T), needle: infer T) usize {...} // Note: T can still only be inferred once, and only at a particular location, but it // can be referred to before that. The procedure would be to resolve all infers first, // and then use them in a second pass to finalize the types of the remaining arguments. // Structural pattern matching on simple types: fn foo(bar: ?*infer T, baz: []const T) bool {...} // However, note that structural inference across custom types is not possible // and will probably never be possible, because type constructors in Zig can be // arbitrarily complex. fn convert(x: ArrayList(infer T)) HashSet(T) {...} // No can do. Use this instead: fn convert(comptime T: type, x: ArrayList(T)) HashSet(T) {...} ``` ### Peer type resolution Another straight-forward possibility is to allow peer type resolution, as suggested by @mlugg in this [comment](https://github.com/ziglang/zig/issues/9260#issuecomment-1026973338). Peer type resolution is enabled by using an `infer` with the same label more than once: ```zig fn max(x: infer T, y: infer T) T { return if (x > y) x else y; } ``` This allows us to call `max(@as(u8, 5), @as(u16, 3))` and get a `u16` as a result. If the function were instead declared as `fn max(x: infer T, y: T) T { ... }`, then a call with different argument types would be an error. Nearly the same thing could be achieved by declaring `fn max(x: infer _, y: infer _) @TypeOf(x, y) { ... }`, but this is less nice syntactically. It may also lead to over-instantiation in some cases: `max(u8, u16)`, `max(u16, u8)` and `max(u16, u16)` would produce separate instances. This can be avoided if the peer type resolution happens at the argument level and is not deferred to the return type calculation. ## Similar proposals This proposal is an improved (I hope) version of something suggested by @YohananDiamond here: [#5893 (comment)](https://github.com/ziglang/zig/issues/5893#issuecomment-854243446). Towards the end of the comment, the following is proposed: ```zig fn max(generic a: T, b: T) T { return if (a > b) a else b; } ``` In the same comment it is pointed out that this makes it somewhat unclear that T is being declared here. The present proposal addresses this shortcoming and generally makes it clear what and where exactly is inferred. It also leads to a more natural representation of the type of a generic function, but is otherwise only a minor reshuffling of keywords. Edit: There's also the proposal #6997, which provides a partial solution to the type signature imprecision problem. ## Summary Advantages over status quo: * Preserve more type information for docgen, metaprogramming and error messages * Reduce visual noise and unintuitive keyword naming * Express intent more clearly Optionally also: * Remove constraints on order of arguments * Allow structural pattern matching without `std.meta` in simple cases It should also be mentioned that inference remains simple and fully deterministic and does not open the door to template metaprogamming or some such.

permutationlock · October 5, 2023, 11:58pm

@AndrewCodeDev Thanks for pointing me to those issues, I assumed that this must have been discussed a lot in the past but hadn’t seen those before. My library was just an exploration of what I could do with what is currently available and without changing the language features: I am not even advocating that type traits in the way I’ve implemented them are the way to go.

I’ll admit that I personally don’t usually use LSPs, so I wasn’t thinking from that perspective.

I tried using my library with the style presented here we could have something like:

fn myGenericFunction(comptime T: type) Returns(
    MyReturnType,
    trait.implements(MyTrait).assert(T)
) {
    // function body
}

Where Returns is a hack like

pub fn Returns(comptime T: type, comptime _: void) type { return T; }

Combined with your proposal to print the full function declaration in compile time error messages, this could get close to having concepts/traits with nice error messages, without adding complexity to the language.

AndrewCodeDev · October 6, 2023, 12:09am

@permutationlock That’s another really cool idea. Very interesting stuff.

I’d like to workshop this a bit more, so I’ll come up with some more ideas and post here as we move forward.

One thing I’d recommend is changing the name “Returns” to “Contract” and then if the user wants, use the Returns function in one of my previous posts for added readability.

fn myGenericFunction(comptime T: type) Contract(
    trait.implements(MyTrait).assert(T),
    Returns(MyReturnType) // I personally like returns here
) {
    // function body
}

One of the reasons I like using boolean logic is that it naturally supports intuitive composition. I haven’t read much into your library so far, but how would you intend to handle or statements. I suppose you could create a custom object that has the or statement inside of it and use the meta/traits imports from std. That said, I like on-site composability because it reduced boilerplate.

permutationlock · October 6, 2023, 12:13am

I’ll think about it more. I think I have a nice idea in mind that would allow composition. I like the idea of changing to contract putting returns there. It feels a little weird calling a function just for labeling, but then again all of this is a little hacky.

Implementing Generic Concepts on Function Declarations

anytype function args

`anytype` function args