literal number from a conditional expression is not being coerced to assignee type

[JPGygax68]

The following assignment

atlas.TexWidth = if (surface_sqrt >= 4096*0.7) 4096
    else if (surface_sqrt >= 2048*0.7) 2048
    else if (surface_sqrt >= 1024*0.7) 1024
    else 512;

yields the error

.\src\imdrawlist.zig:747:18: error: values of type 'comptime_int' must be comptime known
            else if (surface_sqrt >= 1024*0.7) 1024

To get rid of the error, I had to use @as(u32, ...) on all 4 constants.

It seems to me that type coercion should happen automatically here, since the required type is known.

[alexnask]

I would personally have expected for peer type resolution to kick in here and only require a single @as in any of the branches.

[joachimschmidt557]

The peer type resolution kicks in when the last else branch has the @as: https://zig.godbolt.org/z/jt6kEB

When other branches have the @as, this does not seem to work.

[alexnask]

Huh, interesting, I guess this makes some sense as it is the matching branch to the root if expression.

[JPGygax68]

This explains the behavior, but is there a reason why coercion can't or shouldn't happen without an @as() ?

[ghost]

I think the problem is that result location stuff doesn't work through nested branches. if a else if b else c is technically nested (it's the same as if a else (if b else c)).

Result location works on a one-level-deep conditional like x = if (a) y else z.

Your example will work with an @as cast on one of the last two values, since that is the innermost if/else expression. Peer type resolution will propagate that type outwards.

I think the reason result location doesn't work through nested branches is just that no one has implemented it yet, and i hear that part of the compiler codebase is gnarly.

Similar issues: #3750, #4255, #4629

[andrewrk]

@dbandstra is correct. The current plan is to implement this correctly in stage2 only and then delete the stage1 codebase.

[andrewrk]

duplicate of #4629 and fixed in master branch.