Feature request: Generic comptime variables

[sudokit]

Support for passing compile time constants in generics would be useful. for example something like:

struct Vec<T, N: usize> {
    data: T[N];
}

Not sure how he syntax should be, but could maybe be something like:

struct Vec<T, comptime N: usize> {}

or just

struct Vec<T, comptime N> {}

not sure how it would go mixing the types and constants in same generic definition.

[oschijns]

What is the status on this issue ?

[lunardoesdev]

let me vote against this feature, current comptime system is simple, maybe it can be enhanced to allow comptime generation outside of function blocks, but otherwise it is more than enough for a programming language. There is no need for complex comptime type system. Generics do have their purpose of sharing same code among different types implementing same interface, but what useful can you do by passing comptime variable to generic? in Zen-C, there is comptime block allowing you to generate portions of code using printing functions, and there is no such thing as comptime variable as part of type system.

[oschijns]

For example, with this feature I could implement fixed point numbers as Fix<I, comptime P> which would make trivial to specify variants of fixed point numbers such as Fix<i32, 12>, Fix<i16, 8> or Fix<i8, 2>. I've looked into doing the same in Vlang and it was not as convenient essentially because of the lack of constant values in generics.

There are other cases where you want to declare a type with a fixed size which may vary depending of the dev's needs

struct Storage<T, comptime B> {
    buffer: T[B];
    ordering: u32[B];
}

[sudokit]

I see your point @lunardoesdev, buuut

There is no need for complex comptime type system.

I fail to see how adding comptime variables to generics would make the type system more complex. Coming from Odin, having comptimes be passed to "generics" makes it really useful, for example for vectors, or like @oschijns showcased in his examples.

there is comptime block allowing you to generate portions of code using printing functions, and there is no such thing as comptime variable as part of type system.

I looked into implementing the vector, for example, using that system, but it was not robust enough at the time. Although I would argue doing it with the comptime print block would make it unnecessarily complex and convoluted, especially with bigger logic.

[lunardoesdev]

lets look at the exact Storage<T, n>. the problem is that you'll have to make all your functions to have proper overloads for all n that you use in code. Probably you will have some weird way to automate that, and that will be exactly lots of complex comptime logic, comptime functions, comptime variables and bloated resulting binary size that get additional functions for every comptime n in Storage<T, n>. you get a lot of Type<a,b, N> in your code. You get undebuggable comptime logic. You get slow build times.

Another point is that we have really good macro system in zen-c, being able to generate text of code allows to have things like compiler plugins. It does need a little additional work to be used with comfort (like adding multiline strings), but even now you can print "struct Storage{n}" and implement needed traits for it if really needed. That stilll requires you to put function definitions for every set of methods for every n in Storage{n} into resulting binary, so it should be used with caution. There is no need to replace that macro system with comptimes from zig. I really like the unique approach of zen-c , please do not turn it into zig.

[lunardoesdev]

Let's say you want a method to sum up two Fixed numbers, Fixed<i32, 5> and Fixed<i32, 6>. If you want to represent that in type system, you'll have to create fn sum(Fixed<i32,5>, Fixed<i32, 6>) that returns some other Fixed pre-thought type. Thats a nice case for complex scala-like runtime system with dependent types, not for low-level language. CPU is still only capable of computing two or four types of numbers, and you'll have to do type conversion to make it do so, so you won't even get your code running faster using so precise types.

[oschijns]

In the example you provided, yes to add two numbers with different precision, you have to adjust one to the same precision as the other.
Let's say we pick the first as the referential, we would get

fn sum(a: Fix<i32, 5>, b: Fix<i32, 6>) -> Fix<i32, 5> {
   return Fix<i32, 5>{ inner: a.inner + (b.inner >> 1) };
}

Now if we make it more generic, we could get

fn sum<I1, const P1, I2, const P2>(a: Fix<I1, P1>, b: Fix<I2, P2>) -> Fix<I1, P1> {
    comptime {
        if P1 > P2 {
            code("let tmp = b.inner << (P1 - P2);");
        } else if P1 < P2 {
            code("let tmp = b.inner >> (P2 - P1);");
        } else {
            code("let tmp = b.inner;");
        }
    }
    return Fix<I1, P1>{ inner: a.inner + tmp };
}

Normally, you only generate the functions for the type you actually use so I don't really see the issue with this.

[lunardoesdev]

The task at hand is having fixed numbers of any size one wants

One solution is to do it like it's done in c/c++, which is treating "any" as dynamic value and doing dynamic allocations, having vector Vec that is pointer and length. This solution is clean, it doesn't need many functions with overloads for different kinds of same type to bloat resulting binary, you can make Vec interop with Vec without generating another bunch of functions in the end binary on the fly, and also you get runtime dynamic size that can be not compiletime known for free.

Your solution solves the same problem, but it wont give you dynamic not compile-time known size, it's a lot harder to read and write, it's very hard to think about how do I work with two different values of same type but slightly different kind, it requires bazillion type conversions if you use the same approach for all the code you write.

Your approach is not impossible, it does exist in zig and probably in rust, but I really want zen-c to not be Rust or Zig, to be some thing more practical that I'd want to work with and read other people's code.