@intFromFloat must have a known result type | Zig Programming Language | Page 1

limpid gorge Jun 10, 2025, 10:27 AM

#

i'm trying to call a function with a i32 as argument, i pass this:

engine.backbuffer_height - @intFromFloat(clip.y + clip.h)
       ^i32                                   ^--------^f32

i get:

src/game/nk.zig:349:48: error: @intFromFloat must have a known result type
                    engine.backbuffer_height - @intFromFloat(clip.y + clip.h),
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/game/nk.zig:349:48: note: use @as to provide explicit result type

why can't it deduce and cast to i32 why force me to uglify my code even more

elder gyro Jun 10, 2025, 10:39 AM

#

limpid gorge i'm trying to call a function with a i32 as argument, i pass this: ```rs engine...

the compiler refusing to "deduce" this forces you to think about what you actually want to happen, since i32 cannot store all possible f32 values. Part of the "Zig Zen" is "Communicate intent precisely" and this sort of stuff is part of that imo

limpid gorge Jun 10, 2025, 10:40 AM

#

i would have agreed if there was a :

@i32FromFloat()

#

even tho, i want the compiler to deduce it

elder gyro Jun 10, 2025, 10:40 AM

#

there is: @as(i32, @intFromFloat(x))

limpid gorge Jun 10, 2025, 10:41 AM

#

nah, that makes the function unreadable

elder gyro Jun 10, 2025, 10:41 AM

#

const y: i32 = @intFromFloat(clip.y + clip.h);

limpid gorge Jun 10, 2025, 10:42 AM

#

now you want me to change my code, from a simple function call, to me storing multiple variables, increasing cognitive load

#

compiler should deduce most stuff

#

if it can't, there should be utilities to deal with it

#

expecting people to stack multiple @'s is not good

elder gyro Jun 10, 2025, 10:43 AM

#

the design of the zig language disagrees at the moment, maybe this sort of stuff will be less verbose in the future, but that's the way it is now

#

imo the looseness of C implicit casts lead to a lot of bugs so i appreciate zig's approach, i've learned to embrace the verbosity and stop worrying about trying to fit everything into the minimum possible vertical/horizontal source code space

limpid gorge Jun 10, 2025, 10:47 AM

#

i agree, but the verbosity of these @ makes code less readable

elder gyro Jun 10, 2025, 10:49 AM

#

imo

const clip_bottom: i32 = @intFromFloat(clip.y + clip.h);
const something = engine.backbuffer_height - clip_bottom;

is quite readable, up to you how you want to handle this sort of stuff, though

limpid gorge Jun 10, 2025, 10:51 AM

#

again, i'm not gonna store billions of variable to make the compiler happy, my example was extracted from an existing project, of course it's not as simple as this

#

all stem from the fact that i cant rect_a + rect_b in zig already, so i have to work with bunch of things like that

elder gyro Jun 10, 2025, 10:52 AM

#

could be wrong, but i don't think the above would actually lead to a difference in code gen to @as(i32, @intFromFloat(clip.y + clip.h))

limpid gorge Jun 10, 2025, 10:54 AM

#

maybe, but the cognitive load is less if my function call remain a one liner

elder gyro Jun 10, 2025, 10:55 AM

#

i guess i'm the opposite, i love splitting things into multiple lines these days, being able to give names to intermediate values helps a lot in being able to understand the code for me

limpid gorge Jun 10, 2025, 10:56 AM

#

i now understand why AstGen.zig is one giant file

elder gyro Jun 10, 2025, 10:56 AM

#

haha, FWIW i've never touched AstGen 🙂

limpid gorge Jun 10, 2025, 10:57 AM

#

i did, to patch the unused error thing lol https://github.com/ryuukk/zig-bootstrap/actions/runs/15506232067

GitHub

++ · ryuukk/zig-bootstrap@6582c73

take off every zig. Contribute to ryuukk/zig-bootstrap development by creating an account on GitHub.

#

i have zig and zag commands

#

zag when i iterate on an idea, and zig when i move on

#

zig zag

#

maybe i should patch the @ now lol

limpid gorge Jun 10, 2025, 11:27 AM

#

i'm thinking of adding @to

        ortho[0][0] = ortho[0][0] / @as(f32, @floatFromInt(engine.backbuffer_width));
        ortho[1][1] = ortho[1][1] / @as(f32, @floatFromInt(engine.backbuffer_height));

        ortho[0][0] = ortho[0][0] / @to(f32, engine.backbuffer_width);
        ortho[1][1] = ortho[1][1] / @to(f32, engine.backbuffer_height);

slate ridge Jun 10, 2025, 12:49 PM

#

limpid gorge i did, to patch the unused error thing lol https://github.com/ryuukk/zig-bootstr...

Why?

#

You are maintaining a fork of the zig compiler?

#

It's not wprth it

limpid gorge Jun 10, 2025, 1:16 PM

#

i'm not a conformist, if it's worth it to me, that's all that matter

#

it's few lines patch only

alpine crescent Jun 10, 2025, 1:37 PM

#

I'm baffled by the fact that you lament a cognitive load increase and suggest patching the compiler in the same thread. You could save the extra @ and make to a function that zig would almost certainly inline. Readable and simple

limpid gorge Jun 10, 2025, 2:02 PM

#

that's the whole purpose of open source

#

my patch won't affect any of your projects, but will improve my sanity

#

You could save the extra @ and make to a function that zig would almost certainly inline. Readable and simple
something that i have to import everywhere? no ty, yall don't understand but that's ok, i'll have my patch

slate ridge Jun 10, 2025, 2:38 PM

#

Yeah I don't understand why you need to patch a language lol

#

Zig is intentionally explicit and verbose, you gonna have a bad time I think

limpid gorge Jun 10, 2025, 2:42 PM

#

i think too many people defend poor choices, wich lead to nobody having the balls to actually call out bad verbosity

#

i don't mind verbosity, when it's concise

#

if you see something bad, say it, you don't need to hide behind ideology

#

experimentation leads to improvements, sometimes

#

pursue that

#

i may be wrong, but i'll find out

slate ridge Jun 10, 2025, 2:56 PM

#

well then

#

zig won't change that 99%

limpid gorge Jun 10, 2025, 2:57 PM

#

said jakub

#

author and owner of zig

slate ridge Jun 10, 2025, 2:58 PM

#

well, you can try if you still want

limpid gorge Jun 10, 2025, 2:58 PM

#

there are many accepted proposals on the zig issue tracker, they are willing to change things if they think it's a good idea

slate ridge Jun 10, 2025, 2:59 PM

#

yeah, if they do

limpid gorge Jun 10, 2025, 2:59 PM

#

exact

#

for now, i'll settle with a patch i'll maintain

slate ridge Jun 10, 2025, 3:00 PM

#

limpid gorge exact

don't think they would remove unused variables error for example

limpid gorge Jun 10, 2025, 3:01 PM

#

oh, yeah, that i agree, i started this zag thing because i agree with them, so i made it a zag command instead

slate ridge Jun 10, 2025, 3:02 PM

#

wait, what?

limpid gorge Jun 10, 2025, 3:02 PM

#

the fork, i set an alias zag

slate ridge Jun 10, 2025, 3:03 PM

#

i started this zag thing because i agree with them
so why you started something that does what the official compiler provides already?

#

unless you wanted the ability to turn it off sometimes

limpid gorge Jun 10, 2025, 3:03 PM

#

that's exactly what i said

#

zag when i iterate on an idea, and zig when i move on

pallid nest Jun 10, 2025, 3:41 PM

#

limpid gorge my patch won't affect any of your projects, but will improve my sanity

the baffling comes from "writing a inline fn to(..) is simpler than patching in a @to(..) builtin, and they'd both look the same"

limpid gorge Jun 10, 2025, 3:57 PM

#

pallid nest the baffling comes from "writing a `inline fn to(..)` is simpler than patching i...

you don't realize how much we are loosing it

the premise:

        ortho[0][0] = ortho[0][0] / cast(float)(vwidth);
        ortho[1][1] = ortho[1][1] / cast(float)(vheight);

what you suggest:

creating a function, and importing the file whenever i need the casting

#

brother

languid copper Jun 10, 2025, 3:58 PM

#

limpid gorge i may be wrong, but i'll find out

I like this philosophy. And I think I agree with you.

Of course I'm just random person number 83, but still.

pallid nest Jun 10, 2025, 4:00 PM

#

limpid gorge you don't realize how much we are loosing it the premise: ``` ortho[0]...

"creating a builtin in the compiler, use a different executable whenever i need to not publish code"
brother

limpid gorge Jun 10, 2025, 4:00 PM

#

pallid nest "creating a builtin in the compiler, use a different executable whenever i need ...

i'd rather fix the issue at the core

pallid nest Jun 10, 2025, 4:01 PM

#

one is less code, idk how the other is a "core fix"

limpid gorge Jun 10, 2025, 4:01 PM

#

but again, that won't affect any of your projects, it's ok if you think that's a bad idea

pallid nest Jun 10, 2025, 4:02 PM

#

patching compiler sounds fine (for unused). just explaining why it sounds inefficient to patch the to one specifically when it can be a function

languid copper Jun 10, 2025, 4:04 PM

#

pallid nest patching compiler sounds fine (for unused). just explaining why it sounds ineffi...

Wait isn't it by definition more inefficient to write the same function over and over in all of your projects?

#

How is it inefficient?

pallid nest Jun 10, 2025, 4:04 PM

#

that assumes ur using multiple projects

#

u could even just patch stdlib

languid copper Jun 10, 2025, 4:05 PM

#

When have programmers ever just had one project??

pallid nest Jun 10, 2025, 4:05 PM

#

i use 0.13.0 specifically for TigerBeetle

languid copper Jun 10, 2025, 4:05 PM

#

pallid nest u could even just patch stdlib

I mean, fair I suppose

pallid nest Jun 10, 2025, 4:05 PM

#

most programs have dev environments specific to the project

limpid gorge Jun 10, 2025, 4:28 PM

#

pallid nest u could even just patch stdlib

why should i want to import anything for my use case?

#

you should take a moment to think about it, at some point before suggesting something, you have to understnd what problem i am trying to solve

#

i'm not tyring to do a HTTP request

#

i'm not trying to save something to a database

#

importing something is out of question

#

creating a function? same, why should i do that

#

you have to stop putting the problem under the carpet and ignore it

#

i choose to solve it

pallid nest Jun 10, 2025, 4:32 PM

#

DrakeNo add a function to stdlib or something else u already import
DrakeYes patch in a new builtin to a fork of the compiler

limpid gorge Jun 10, 2025, 4:33 PM

#

patch it once, solve it forever

#

you don't want to realize how anything other than a builtin is a bad suggestion

slate ridge Jun 10, 2025, 6:07 PM

#

limpid gorge patch it once, solve it forever

that's just overkill for most people

#

maybe not you ig

#

for a hobby project you can even waste some extra time

limpid gorge Jun 11, 2025, 1:20 PM

#

slate ridge for a hobby project you can even waste some extra time

i'm not wasting my time, you'll be the one to waste your time if you don't value debug build performance with your billion small functions

slate ridge Jun 11, 2025, 1:22 PM

#

Debug build performance?

#

Idk, I would use the language the way they want you to use it
Or otherwise go use a different language

limpid gorge Jun 11, 2025, 1:24 PM

#

again, said jakub, author and owner of the zig programming langauge

#

i'm pretty sure andrew would agree with me

#

i understand the reasoning behind it, i however not agree with the solution

#

i'm porting my engine to zig, and already i can see drop in FPS in debug build

slate ridge Jun 11, 2025, 1:27 PM

#

What does drop in FPS have to do with any of this? I'm confused

limpid gorge Jun 11, 2025, 1:31 PM

#

ok, so you are clueless yet you make suggestions

slate ridge Jun 11, 2025, 1:40 PM

#

All I know is you patched unused variables error and were planning to add new builtin

#

No idea what that has to do eith performance

limpid gorge Jun 11, 2025, 1:44 PM

#

you suggest me to create a function to do a cast

#

and that kind of shit is all over the std too, small little function to do basic things

#

it's compounding

slate ridge Jun 11, 2025, 1:49 PM

#

And you think there must be a better way that Andrew would accept

limpid gorge Jun 11, 2025, 1:51 PM

#

he won't accept, hence why my patch

#

i'm not forcing you to agree with me, i'm asking you to not force me to comply

slate ridge Jun 11, 2025, 1:52 PM

#

You want something impossible, an ideal language

limpid gorge Jun 11, 2025, 1:52 PM

#

i never said i want anything

#

i wrote my patch

slate ridge Jun 11, 2025, 1:53 PM

#

Yeah, you wrote it for a reason

limpid gorge Jun 11, 2025, 1:53 PM

#

because i need, that's different 😉

limpid gorge Jun 11, 2025, 2:22 PM

#

2 times slower, just for the login screen

#

left: zig, right: D

#

let's fire the profiler

slate ridge Jun 11, 2025, 2:39 PM

#

And does your patch make it faster or what

limpid gorge Jun 11, 2025, 2:43 PM

#

no, but it'll help not make it much slower

slate ridge Jun 11, 2025, 2:47 PM

#

Huh?

#

How tho

viscid kraken Jun 11, 2025, 4:03 PM

#

limpid gorge 2 times slower, just for the login screen

What's the code difference between these?

limpid gorge Jun 11, 2025, 4:07 PM

#

not much, graphics part is mostly 1:1, assets is async io (zig) vs thread (d) but that doesn't matter, the issue happens inside the UI code, wich is C (nuklear), the difference is how zig translates C vs D's importc, i suspect it does bunch of useless copies, that's what the profiler suggests

#

i rewired the memcpy call from nuklear to zig, that helps but still slow

#

#

left zig, right D, both in the login screen same UI code

viscid kraken Jun 11, 2025, 4:11 PM

#

Is this in release mode or debug?

limpid gorge Jun 11, 2025, 4:11 PM

#

debug

#

ReleaseFast is on par with D's debug

viscid kraken Jun 11, 2025, 4:12 PM

#

Is D's optimised faster?

limpid gorge Jun 11, 2025, 4:12 PM

#

looks like it is

#

but release build is almost 2x faster than ReleastFast too

#

perhaps a bug in zig translate-c

viscid kraken Jun 11, 2025, 4:14 PM

#

Yeah

limpid gorge Jun 11, 2025, 4:14 PM

#

nuklear code base is massive

viscid kraken Jun 11, 2025, 4:14 PM

#

Wait are you translatec on the source or

#

The header

limpid gorge Jun 11, 2025, 4:14 PM

#

no, that's what zig does

viscid kraken Jun 11, 2025, 4:14 PM

#

What does d do?

#

Does it do it like zig

limpid gorge Jun 11, 2025, 4:14 PM

#

    // nuklear
    exe.addIncludePath(b.path("src/c/nuklear/"));
    exe.addCSourceFile(.{ .file = b.path("src/c/nuklear/nuklear.c"), .flags = &.{ "-std=c11", "-Wl,--allow-multiple-definition" } });

#

it translate C to zig

viscid kraken Jun 11, 2025, 4:15 PM

#

so just the header

limpid gorge Jun 11, 2025, 4:16 PM

#

pub const c = @cImport({
    @cDefine("NK_INCLUDE_VERTEX_BUFFER_OUTPUT", "");
    @cInclude("nuklear_all.h");
});

viscid kraken Jun 11, 2025, 4:16 PM

#

Does d transpile the code to d code or does it do it like zig and only get the header translated?

limpid gorge Jun 11, 2025, 4:16 PM

#

D parses C code directly

#

https://dlang.org/spec/importc.html

ImportC - D Programming Language

D Programming Language

#

it's like zig translate-c except it doesn't save to disk

viscid kraken Jun 11, 2025, 4:18 PM

#

Oh yeah I think that would be what's making it slower

#

d looks like it translates the C into d without invoking a C compiler

#

I think if zig could do that it could benefit from optimisations in the same compilation unit

#

But it can't so I think that's why it's slow

#

If you had a zig port 1:1 of nuclear it would match d I think

limpid gorge Jun 11, 2025, 4:26 PM

#

oh i thought zig was doing the same

viscid kraken Jun 11, 2025, 4:28 PM

#

Oh nah zig invokes clang

#

Without goto like d I don't think C code can be 1:1 converted to zig code

limpid gorge Jun 13, 2025, 5:00 PM

#

compiling nukear myself solves the performance issue

#

// nuklear
    exe.addIncludePath(b.path("src/c/nuklear/"));
    // exe.addCSourceFile(.{ .file = b.path("src/c/nuklear/nuklear.c"), .flags = &.{ "-std=c11", "-Wl,--allow-multiple-definition" } });
    exe.addObjectFile(b.path("src/c/nuklear/lib/nuklear.a"));

viscid kraken Jun 13, 2025, 5:01 PM

#

how are you compiling it?

limpid gorge Jun 13, 2025, 5:01 PM

#

clang -c -Wall -std=c99 -fPIC -O2 -o tmp/nuklear.o nuklear.c
llvm-ar rc tmp/nuklear.a tmp/nuklear.o

viscid kraken Jun 13, 2025, 5:02 PM

#

what if you put those flags into zig's addCSourceFile?

limpid gorge Jun 13, 2025, 5:02 PM

#

good idea, even tho i tried all kind of optimize= modes

#

:1:1: error: unknown argument '-fPIC '; did you mean '-fPIC'? lol

#

oh i had a white space

viscid kraken Jun 13, 2025, 5:04 PM

#

space?

#

yeah

limpid gorge Jun 13, 2025, 5:05 PM

#

INFO: fps: 6517 0.000144 with same flags
INFO: fps: 8311 0.000118 with the static lib built myself, same flags

#

but looks better already

#

it's x86 backend

viscid kraken Jun 13, 2025, 5:06 PM

#

I think it still calls to clang for c source files but I'm not sure

limpid gorge Jun 13, 2025, 5:06 PM

#

i don't think it does

viscid kraken Jun 13, 2025, 5:06 PM

#

idk if aro is being used

limpid gorge Jun 13, 2025, 5:06 PM

#

because ReleaseFast also was slow

viscid kraken Jun 13, 2025, 5:06 PM

#

does non x86 backend change it?

#

because the x86 backend has almost no optimisations right now

limpid gorge Jun 13, 2025, 5:08 PM

#

INFO: fps: 6897 0.000147
INFO: fps: 8828 0.000113

better but same gap

#

all tests in debug

viscid kraken Jun 13, 2025, 5:08 PM

#

what about in release fast?

#

because the lib you compiled yourself with clang should be as fast as the one zig compiles since its just calling to clang for c compilation

#

unless you've overriden the target

limpid gorge Jun 13, 2025, 5:10 PM

#

INFO: fps: 10353 0.000095
INFO: fps: 10011 0.000115

same, interesting

viscid kraken Jun 13, 2025, 5:10 PM

#

is it faster now?

limpid gorge Jun 13, 2025, 5:11 PM

#

so x86 backend also compile c code, wich produces bad code

viscid kraken Jun 13, 2025, 5:11 PM

#

limpid gorge so x86 backend also compile c code, wich produces bad code

well yeah its an in development backend

#

its just not as optimised as something as mature as llvm

glossy tangle Jun 13, 2025, 5:12 PM

#

x86_64 backend doesn’t compile c code, neither does the llvm backend. Zig always uses clang for that.

limpid gorge Jun 13, 2025, 5:12 PM

#

ok, so that's reassuring

viscid kraken Jun 13, 2025, 5:12 PM

#

glossy tangle x86_64 backend doesn’t compile c code, neither does the llvm backend. Zig always...

^

viscid kraken Jun 13, 2025, 5:12 PM

#

viscid kraken I think it still calls to clang for c source files but I'm not sure

.

glossy tangle Jun 13, 2025, 5:13 PM

#

Translate-c is for translating headers to Zig to easily link with C libraries without having to write the binding manually.

#@intFromFloat must have a known result type