Informal proposal: "Type Inference for Binary Operators Involving Predictable Functions"

Brainstorming
1

I came up with a proposal, so I immediately started working on it and finished it, but I didn’t know that Zig isn’t accepting proposals, and I got a little sad :cry:
Please let me know everyone’s opinions on this proposal!!

1 Like
2

Isn’t this just type coercion?

3

Yes, this proposal is solely for reducing the amount of code, and it does not change the behavior of the code
Personally, I dislike using “@as” in code, so I came up with this proposal

4

I forgot to add this in proposal, but this can also be applied to equality operators and such. For example:

const A = struct {
    a: usize,

    pub const init_1: A = .{ .a = 1 };
    pub const init_2: A = .{ .a = 2 };
};

pub fn main() void {
    const some_known_a: A = .init_1;

    if (some_known_a == A.init_2)
        @compileLog("intended");
}

Here,

some_known_a == A.init_2

can be written as

some_known_a == .init_2

This is particularly effective when the struct name is long. For example:

const a: SomeLongStructName = .init_1;

if (a == SomeLongStructName.init_2)
  @compileLog("intended");

It can be written as follows:

const a: SomeLongStructName = .init_1;

if (a == .init_2)
  @compileLog("intended");

Also, “Predictable function” in proposal should be called as “Node that uses type”, which is more appropriate

5

So, it’s just a verbosity issue that you don’t like about using the built-in expressions?

If you want to simplify it for doing high-level work, you can just create an abstract helper. Or even a whole module of helpers if you’re using them a lot. I created wrappers for most of the built-ins for the project I’m tinkering with atm, it works great, and I just have to import and then drop the @ symbol and they just work.

I really like the verbosity because it is extremely clear what’s happening, and it allows for some interesting type-safe trickery. But I’m mostly doing branchless and reversible projects so obviously a special use case.

1 Like
6

Hmm, yeah, you’ve hit a sore spot there.

But at least in the equality operation example I mentioned earlier, it doesn’t seem to make the code harder to understand. Maybe that’s because the code is physically “separated”. Or rather, binary operations on things like structs, where there’s less stuff in the code, might be easier to follow. On the other hand, “numerical” binary operations involving integers, floats, and such could get tricky because the types of both operands might differ

This is a bit of a hassle… I could think about adding an option to build.zig to enable or disable this proposal, but that too overkill