Proposal: Allow TypeOf to be used immediately after a name of a parameter is declared

[Rocknest]

Currently a function parameter is only visible to the @TypeOf after next parameter's scope starts.

fn example1(x: @TypeOf(x)) void {}
// error: use of undeclared identifier 'x'

fn example2(x: anytype, y: @TypeOf(x)) void {}
// works; when used as `example2(arg, arg)` it is equivalent to example1

I propose to allow to use @TypeOf after only a name of a parameter is declared. Can it be useful? Yes, that would allow to put type constraints in a function signature instead of a function body. This basically #1669 without the new syntax.

// status quo
fn isWriter(comptime T: type) bool {...}

fn write1(w: anytype, data: []const u8) void {
    if (!comptime isWriter(@TypeOf(w))) @compileError("wrong type");
    w.write(data);
}

// with this proposal
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);
}

What happens when i provide a type which is different from the type that @TypeOf returned? Compiler will check if the value of the argument is coerceable to the new type, if it is not then its a compile error.

Optional Part

If this proposal is implemented then these two expression will be equivalent:

fn example1(x: @TypeOf(x)) void {}
fn example2(x: anytype) void {}

This means we could remove keyword 'anytype'. x: @TypeOf(x) looks a bit verbose to me, see #1669 (comment) for an alternative builtin @Infer(), in short instead of overloading @TypeOf create a new builtin that implements proposed functionality x: @Infer(), x: Constraint(@Infer(), isWriter).

[marler8997]

This is a pretty interesting idea. It took me a few minutes to see what you were getting at.

So this would mean that when the compiler is evaluating each parameter type, if the symbol for that parameter appears in that type expression, then it resolves to the value passed in for that parameter by the caller. So if I have

fn foo(x: @TypeOf(x)) void { }

foo("hello");
foo(123);

On each of the calls above, @TypeOf(x) would evaluate to @TypeOf(123) and @TypeOf("hello").

This also adds an new semantic feature, the ability to normalize parameter types. For example, @TypeOf("hello") would evaluate to something like *[5:0]const u8, but we could normalize it to a string slice

fn NormalizedString(comptime T: type) type {
   // if a pointer to an array, return the slice type
   ...
}
fn foo(x: NormalizedString(@TypeOf(x))) void { }

Wow this is a really interesting idea!

[Rocknest]

On each of the calls above, @TypeOf(x) would evaluate to @TypeOf(123) and @TypeOf("hello").

Exactly, that would make possible type constraints aka concepts, arbitrary type manipulation and more. For example a function that widens the type of a generic parameter:

fn WidenIntOrFloat(comptime T: type) type {
    if (T == u8 or T == u16 or T == u32 or T == u64) {
        return u64;
    } else if (T == i8 or T == i16 or T == i32 or T == i64) {
        return i64;
    } else if (T == f32 or T == f64) {
        return f64;
    }
    @compileError("unsupported type");
}

fn example(x: WidenIntOrFloat(@TypeOf(x))) void {}

// const a: u8 = 5; example(a); calls example(u64)
// const b: u32 = 55; example(b); also calls example(u64)
// const f: f32 = 1.5; example(f); calls example(f64)

[codehz]

@Rocknest I disagree the second idea, it make parameter becomes to a undecidable state(both for human and compiler)

Consider following code

fn Evil(comptime T: type) type {
    return struct { // or anything that will create new type
        const I = (if (@hasDecl(T, "I")) T.I else 0) + 1;
    };
}
fn problem(arg: Evil(@TypeOf(arg))) void {
    @compileLog(@TypeOf(arg).I); // how to solve the equation 
}
comptime {
    problem(.{});
}

Although it is theoretically possible to report errors early by limiting the evaluation depth.

Update: use .{} insteads of struct { const I = 0; }

[daurnimator]

I think this is a great idea that solves #1669 in an intuitive way.

[daurnimator]

@codehz I'm not sure where the issue is with your snippet; comptime calls are cached if that's what you're worried about?

[Rocknest]

@codehz Where is the problem exactly? Given your code:

fn Evil(comptime T: type) type {                               // line 1
    return struct {  const I = T.I + 1;  };                    // 2
}
fn problem(arg: Evil(@TypeOf(arg))) void {                     // 4
    @compileLog(@TypeOf(arg).I);                               // 5
}

problem(struct { const I = 0; }{});                            // 8

Lets see how it is executed at comptime step by step:

#1 problem(struct { const I = 0; }{})
   | types[1] = struct(line=8, I=0)
   | call("problem", (type=1, value={}))

#2 fn problem(arg: Evil(@TypeOf(arg))) void {
   | args[1] = (type=1, value={})
   | var[1] = TypeOf(args[1]) // (type=type, value=1)
   | var[2] = call("Evil", (var[1]))

#3 return struct { const I = T.I + 1; };
   | args[1] = (type=type, value=1)
   | var[1] = (types[args[1].value]) // struct{line=8, I=0}
   | var[2] = (var[1].I + 1) // 0+1
   | types[2] = struct(line=2, I=(var[2]))
   | return: (type=type, value=2)

#4 fn problem(arg: Evil(@TypeOf(arg))) void {
   // continue #2
   | var[2] = (type=type, value=2)
   | var[3] = (types[result.value]) // struct{line=2, I=1} 
   | var[4] = (types[args[2].type]) // struct{line=8, I=0}
   | var[5] = canCoerce(var[3], var[4]) // false
   | if (var[5] == false) compileError(msg="expected type 'struct:2', found 'struct:8'")

As you can see control flow will not even reach compileLog statement. A compile error would be emited:

error: expected type 'struct:2', found 'struct:8
| problem(struct { const I = 0; }{});  
|         ^
note: type defined here
| fn problem(arg: Evil(@TypeOf(arg))) void {
|                 ^

[Rocknest]

Simulated in status quo Zig: https://godbolt.org/z/6KKP47
As you can see no problem here, a nice compile error is emitted.

fn Evil(comptime T: type) type {         
    return struct { const I = T.I + 1; }; 
}
fn problem(_arg: anytype, arg: Evil(@TypeOf(_arg))) void {
    @compileLog(@TypeOf(arg).I);                               
}
comptime {
    const a = struct { const I = 0; }{};
    problem(a, a);
}

[codehz]

fn Evil(comptime T: type) type {         
    return struct { const I = (if (@hasDecl(T, "I")) T.I else 0) + 1; }; 
}
fn problem(_arg: anytype, arg1: Evil(@TypeOf(_arg)), arg2: Evil(@TypeOf(arg1)), arg3: Evil(@TypeOf(arg2))) void {
    @compileLog(@TypeOf(arg1).I); // 1
    @compileLog(@TypeOf(arg2).I); // 2
    @compileLog(@TypeOf(arg3).I); // 3
}
comptime {
    problem(.{}, .{}, .{}, .{});
}

https://godbolt.org/z/P7a5af
fixed/// and original post has been updated
@Rocknest

[kristoff-it]

I find this syntax to be a bit confusing. While the concept is legitimate, it's an edge case that requires a leap in understanding compared to other uses of @Type(). With anytype you still have to take a moment to think about what it does exactly, the first time you encounter it, but at least you don't have to fight any "weird" tautological syntax while doing so.

I'm not sure getting rid of a keyword is reward enough for the price of "hiding" an otherwise very friendly and convenient feature.

[tadeokondrak]

I think solving the issues this solves is great, but this syntax is pretty hard to understand and explain.
The rule that when the parameter name is mentioned in the type expression the function becomes a generic function is pretty subtle.

[Rocknest]

@kristoff-it it is not a goal to remove the keyword, the idea is to give more power to userland so features like type constraints, type manipulation etc can be implemented. I think anytype not much less weird and confusing, but its a more familiar concept because it exists in other languages.

@tadeokondrak it does not have to be @TypeOf, it can be a new builtin with a more descriptive name, see the last paragraph of the proposal.

[kristoff-it]

it is not a goal to remove the keyword, the idea is to give more power to userland so features like type constraints, type manipulation etc can be implemented.

@Rocknest for type constraints we can already implement everything (simply by putting the typechecking at the beginning of the function), what we would get from #1669 (or this proposal) is basically only convenience, I think. What do you mean with "type manipulation"?

[Rocknest]

@kristoff-it yes we can do that in status quo Zig, but it is not a part of a function prototype, and most of the time users do not bother to add checks and if something not used properly you get a compile error somewhere deep in the code. Its a convenience that would encourage to write more expressive, type-safe and fail-fast code. For a basic example of "type manipulation" see #6615 (comment)

[michal-z]

Nice idea but I agree with @kristoff-it - this feature just adds a bit more convenience by introducing a new way of doing the same thing. I think that type checking at the beginning of the function is perfectly fine.

Actually I find below easier to understand.

fn WidenIntOrFloat(comptime T: type) type {
    if (T == u8 or T == u16 or T == u32 or T == u64) {
        return u64;
    } else if (T == i8 or T == i16 or T == i32 or T == i64) {
        return i64;
    } else if (T == f32 or T == f64) {
        return f64;
    }
    @compileError("unsupported type");
}

fn example(x: anytype) void {
  WidenIntOrFloat(@TypeOf(x));
}

[ikskuh]

Nice idea but I agree with @kristoff-it - this feature just adds a bit more convenience by introducing a new way of doing the same thing. I think that type checking at the beginning of the function is perfectly fine.

I don't think so. I really like the idea, as it allows reducing code bloat. Consider the std.fmt namespace which currently explodes into myriads of functions, each of which does a pretty similar job.

With this proposal, the explosion of types can be reduced a lot:

const AnyConstSlice(comptime T: type) type {
    return []const std.meta.Child(T);
}

fn car(slice: AnyConstSlice(@TypeOf(slice))) std.meta.Child(@TypeOf(slice)) {
    return slice[0];
}

fn cdr(slice: AnyConstSlice(@TypeOf(slice))) @TypeOf(slice) {
    return slice[1..];
}

test "explosion"
{
    var first_0 = car("1");
    var first_1 = car("12");
    var first_2 = car("123");
    var first_3 = car("1234");
}

This would only instantiate one car function (which is fn car([]const u8) u8) instead of four functions:

• fn car(*const [1]u8) u8
• fn car(*const [2]u8) u8
• fn car(*const [3]u8) u8
• fn car(*const [4]u8) u8

But it's obvious in this example also that @TypeOf(x) isn't the best syntax and maybe something like @Inferred() is better here:

fn car(slice: AnyConstSlice(@Inferred(slice))) std.meta.Child(@TypeOf(slice)) {
    return slice[0];
}

or even more restrictive:

fn car(slice: AnyConstSlice(@Inferred())) std.meta.Child(@TypeOf(slice)) {
    return slice[0];
}

To me, it looks like this proposal is better than #1669, as it solves the same problem, but also allows code optimizations as the ones above.