remove the destination type parameter from all cast builtins

[andrewrk]

@as is unchanged. These are affected:

• @floatCast
• @intCast
• @alignCast
• @bitCast
• @errSetCast
• @ptrCast
• @truncate

The motivation here is to prevent bugs. Here's an example case:

const Data = struct {
    bits: u8,
};

fn updateBits(data: *Data) void {
    // ...
    const y: usize = indexOfSomethingGuaranteedToFitInBits();
    data.bits = @intCast(u8, y);
    // ...
}

Here, we obtain y, a usize but for whatever reason is guaranteed to fit into the bits field of Data. So we use @intCast here to cast it.

Now, we rework the code, and actually we need to add some more bits, making it a u16:

const Data = struct {
    bits: u16,
};

fn updateBits(data: *Data) void {
    // ...
    const y: usize = indexOfSomethingGuaranteedToFitInBits();
    data.bits = @intCast(u8, y);
    // ...
}

We've now introduced a bug into the code. The bits field is updated, but the @intCast is still casting too small. The lack of type inference here has actually made the code buggier.

The original code theoretically should have used data.bits = @intCast(@TypeOf(data.bits), y) however this is so cumbersome that it's rarely done in practice, especially when data.bits is a more complicated expression.

With this proposal, the original code would look like this:

const Data = struct {
    bits: u8,
};

fn updateBits(data: *Data) void {
    // ...
    const y: usize = indexOfSomethingGuaranteedToFitInBits();
    data.bits = @intCast(y);
    // ...
}

And the updated code (which only changes the type of the bits field to u16) remains correct.

With this proposal, it is still possible to get the older semantics:

const Data = struct {
    bits: u8,
};

fn updateBits(data: *Data) void {
    // ...
    const y: usize = indexOfSomethingGuaranteedToFitInBits();
    data.bits = @as(u8, @intCast(y));
    // ...
}

A cast operation with an inferred result location type would be a compile error:

test "example" {
    var y: i32 = 1;
    const x = @intCast(y); // error: unable to infer result type \n hint: coerce the result using `@as`
}

[zigazeljko]

Why are @bitCast and @ptrCast also affected? The issue with casting too small does not occur there.

[pixelherodev]

## My understanding of the original proposal ### Problem If you change the type of a value, casts may give unintended results, causing subtle bugs. ### Proposed solution Remove the explicit type given to casts, and use the destination type instead. ## Counter-proposal I fully agree that in the examples given, changing the value's type will be a likely source of subtle bugs. This is an issue we should be solving. However, I do not agree with the proposed solution. The problem with this proposal, to me, is that it makes some usages less explicit, and makes it more difficult to explicitly specify the target type. ```zig // Before the proposal // I want to use whatever type foo specifies. If it changes, I want to // change the type we cast to. foo(@intcast(@typeinfo(foo).args..., bar)); // I want to use u8. If the arg type to baz changes, I don't care. baz(@intcast(u8, bar)); // After the proposal // This is clearly much cleaner. foo(@intcast(bar)); // This is much clunkier, even if it's not a big deal for simpler cases. baz(@as(u8, @intcast(bar)); ``` The only way to know the type of `@intCast(bar)` in the argument to foo is to find the definition of `foo`. This is true both before and after the proposal. The proposal clearly makes it much cleaner to write (and much easier to read, as there's less weird type lookup to sift through). The cast to a u8, on the other hand, is clunkier than before, and unpleasant both to write and to read. Sobeston brought up on Discord the idea of using an @ResultType() builtin instead, and I think this is a good idea. The example would change to the following: ```zig foo(@intcast(@ResultType(), bar)); baz(@intcast(u8, bar)); ``` Now, both cases are both explicit *and* clean. This gets rid of clunky type lookups for cases where we want to use the destination's type, without making cases with explicit types more annoying to write. As a bonus, both cases look nearly identical, and it's easier to read.

[michal-z]

Maybe we should allow this:

data.bits = @intCast(_, y);

In this case @intCast would try to infer the type. This would be consistent with array syntax ([_]).

[pixelherodev]

I like that idea.

[andrewrk]

Why are @bitCast and @ptrCast also affected? The issue with casting too small does not occur there.

Consistency across casting primitives. Note that callsites where this is inconvenient are very uncommon, because of this pattern:

const b: u32 = @bitCast(a);
const y: *u32 = @ptrCast(x);

// This is much clunkier, even if it's not a big deal for simpler cases.

@as isn't supposed to be clunky. Any clunkiness is a syntax flaw. Type coercion is supposed to be encouraged and one of the most syntactically simple things to do. For the purposes of this proposal, it should be assumed that @as is not clunky.

[Snektron]

One thing i don't like about both @andrewrk and @michal-z's proposals is that it adds functionality especially tailored for these built ins. I believe that the latter proposal is more promising, provided this functionality is extended to be valid for all generic functions. I do think though that it could generate problems with functions where multiple comptime parameters are provided, but that could be solved simply by stating that _ is equal to the expected type of the expression. Another option would be a new builtin which returns the expression's expected type, which on one hand would be more readable as it directly states whats happening, but on the other hand you would also need to type more (a thing which is also gained by removing the destination type).

I'm not sure whether i'm a fan of this type if inference, but in my opinion it beats @andrewrk's initial proposal as it is both more orthagonal (and doesn't provide a feature specific to these builtin calls), and it is clearer to the reader that the destination type is inferred.

Anyway, as a hypothetical situation, that functionality could again be extended to return types of functions, where the following is valid code:

fn add(a: _, b: _) _ {
  return a + b;
}

This would also allow for example calculation of constants for a certain type:

fn pi() _ {
  const T = @TypeOf(_); // TODO: Improve
  ...
  return calculated_pi_value;
}

As i type this i realize this is more in line with the original proposal though, so the latter paragraph may need some thinking.

[SpexGuy]

I think the original proposal is a great idea. With this, type coercion is the only thing that changes types, and casts define how that change happens and which things are allowed or UB when performing the conversion. Type coercion tends to occur in only three places: moving values between structs and locals, passing values as parameters, and interacting with anytype. In the first two cases, the target type is known. In the third case, the syntax is unified: when assigning to anytype, use @as to change the type and @fooCast if you need to enable special behavior when performing that change.

There's a fourth case where you want to convert to some intermediate type and then coerce to a known target type, but if the target type is different from the cast type you are performing two coercions and IMO the syntax should make that clear.

[SpexGuy]

I also think @ResultType() is a good idea, and should maybe be allowed as the return type of a function, as in @Snektron 's example. But I think that can be a separate proposal.

[frmdstryr]

Doesn't this fix one error but open up (or increase the likeliness) a whole set of other errors?

Eg, What happens above if the data field type is changed from u8 to i8?

The explicit type parameter is often a double check (at least for me) and makes it more clear what is going on without having to dig through more code. @michal-z 's syntax makes the most sense to me because it doesn't lose the explicit intent of the cast (where _ just means I don't care).

[andrewrk]

The explicit type parameter is often a double check (at least for me) and makes it more clear what is going on without having to dig through more code

You have @as for that, and you can use it to accomplish this anywhere. @as feels a bit more cumbersome than I would like it to, it's supposed to be a convenient & happy primitive to reach for any time.

In most cases you should be able to accomplish this by using the form const foo: T = @intCast(bar); and the coercion to T is what you wanted to document.