- @ everywhere, for that I would keep using Objective-C
- Compiled languages shouldn't be using text file imports as modules
- I already have C and C++ for use after free/move errors
Free to disagree, it just means I am not part of the target audience.
Zig doesn't use C-style textual includes, if that's what you mean.
I expect a proper binary module, with native code and symbol table.
@import also has a second mode where the string isn't a Zig source file path, but a package name. AFAIK currently this also just resolves to a package-root zig file, but it could just as well be extended to some sort of binary format, the question is just: why?
If I want to distribute source code I would be using scripting languages.
It is also a nagging point for me when I play around with cargo, which contrary to conan and vcpkg, doesn't do binary libraries.
By the way, C++ modules might get a binary format definition by C++26 (too little time to sort it out by C++23), based on BMI/IFC formats already being deployed in GCC and VC++ respectively.
`pub extern fn foo(c_int) c_int;` etc.
then import with `usingnamespace @import("./my_header.zig");` and now you have a function `foo` that you can call; then you just need to link with the object file that defines it. Is your complaint that you still need the "header" file? What language / tools do you use that let you skip that part?
If you are triggered by the AT character, I recommend that you stay away from Slack and Microsoft Teams.