[forrestthewoods]

> Which, yes, means that the comptime interpreter emulates the target machine.

Reasonable if that’s how it works. I had absolutely no idea that Zig comptime worked this way!

> there's zero benefit to not hiding the host platform in comptime

I don’t think this is clear. It is possibly good to hide host platform given Zig’s more limited comptime capabilities.

However in my $DayJob an extremely common and painful source of issues is trying to hide host platform when it can not in fact be hidden.

[int_19h]

Can you give an example of a use case where you wouldn't want comptime behavior to match runtime, but instead expose host/target differences?

[forrestthewoods]

Let’s pretend I was writing some compile-time code that generates code. For example maybe I’m generating serde code. Or maybe I’m generating bindings for C, Python, etc.

My generation code is probably going to allocate some memory and have some pointers and do some stuff. Why on earth would I want this compile-time code to run on an emulated version of the target platform? If I’m on a 64-bit platform then pointers are 8-bytes why would I pretend they aren’t? Even if the target is 32-bit?

Does that make sense? If the compiletime code ONLY runs on the host platform then you plausibly need to expose both host and target.

I’m pretty sure I’m thinking about zig comptime all wrong. Something isn’t clicking.

[von_lohengramm]

It sounds like the sort of compile-time code that you're talking about is closer to "buildtime" code in Zig, that is Zig code compiled for the host platform and executed by the build system to generate code (or data) to be used when compiling for the target system. As it stands now, there's absolutely nothing special about buildtime code in Zig other than Zig's build system providing good integration.

On the other hand, "comptime" is actually executed within the compiler similar to C++'s `consteval`. There's no actual "emulation" going on. The "emulation" is just ensuring that any observable characteristic of the platform matches the target, but it's all smoke and mirrors. You can create pointers to memory locations, but these memory locations and pointers are not real. They're all implemented using the same internal mechanisms that power the rest of the compilation process. The compiler's logic to calculate the value of a global constant (`const a: i32 = 1 + 2;`) is the "comptime" that allows generic functions, ORMs, and all these other neat use cases.

[CRConrad]

> Why on earth would I want this compile-time code to run on an emulated version of the target platform? If I’m on a 64-bit platform then pointers are 8-bytes why would I pretend they aren’t? Even if the target is 32-bit? Does that make sense?

Nope, sorry, to me it doesn't. If you're cross-compiling for some other platform, then yes, I'd think you want the generated binary to be compatible with the target platform. And in order to verify that that binary code is correct for that target platform, you need to "allocate some memory and have some pointers and do some stuff" as you do on that platform.

So why on Earth would you want stuff -- like pointer sizes and whatnot -- to not be compatible with the target platform, but with whatever you happen to be compiling on? What good is pointer size compatibility with your compiling platform to a user of your end-result binary on the target platform? Looks like the mother of all it-worked-on-my-machine statements: "Whaddaya mean it has memory allocation errors on your machine? I ran it as if for my totally-different machine at compile-time, so of course it works on yours!"