Hacker News Reader

Comment by curist | Hacker News Reader

By using comptime, the statement couldn't be runtime composed, right? That's currently the major holdback for me to spend more time on zig: if using comptime become more common in zig community, the libs could be less flexible to use. It feels sort of like function coloring to me, that the whole call chain also need to pass down the value as comptime variable. I've only spend 2 days with zig, so I would love to learn if I'm wrong on this subject.

View on HN

Only the metadata of the statement is comptime, that is the type annotation for each bind parameters. So if you have this query

    SELECT * FROM user WHERE age = $age{u16}

You _must_ provide a u16 bind parameter. However the value itself is of course not required to be comptime-known, that would make the whole thing unusable.

For what it's worth there are in zig-sqlite variants of the method which bypass the comptime checks; they're not documented properly yet but see all methods named `xyzDynamic`, for example https://github.com/vrischmann/zig-sqlite/blob/master/sqlite....

Generally I wouldn't call zig comptime function coloring. (I have written a prime sieve algorithm that uses the runtime code to precalculate some primes at comptime. Yes, I had to be very careful about what was in the prime number algorithm, but comptime supports that level of complexity and it was certainly possible to call runtime-intended code at comptime.

Can you call comptime-intended code at runtime? No? (Yes? B/c the call site is "in" the runtime code?) But just make it runtime code instead of comptime code?

Often, comptime code couldn’t be executed at runtime because the language features it accesses aren’t available then. But I agree that if a parameter could go either way, you shouldn’t have to write two versions.

Reply on news.ycombinator.com