Hi folks,
Just stumbled upon the fact that newly generated projects with the CLI are putting the imports at the end of the file. I’ve also noticed the same while watching @andrewrk 's awesome Programming without pointers video.
What the rationale / motivation behind this?
My guess, is that because a lot of projects end up having files with dozens of lines of imports and aliasing an import’s modules and types, it pushes down the “meat” of what that file is about. By putting all the imports at the end of the file, it means that on opening a Zig file, you don’t have to first scroll through boilerplate to get to anything important.
It’s like writing an academic paper: all your source references go in the footer or an appendix, not at the start of the paper.
Should we make this the convention for Zig? There’s no reason we have to follow the tradition set by C.
I’ve been a fan of this in other languages. In Zig, I followed the standard set by the stdlib and other projects.
I would support imports-last. The one thing which is a bit unsatisfactory is that otherwise-mature code tends to grow more tests over time, so tests-last makes sense. Something about imports under the tests, and the test suite continuing to grow, tweaks my sense of order.
But scrolling through import spam to get to the meat of what a file does is tedious, so on balance, I consider it the better convention.
Considering that doing so is fairly mechanical, I bet the community could get through the churn this would create in the standard library and compiler fairly quickly.
Not a fan. Zig is supposed to be easy to read, so it makes sense to see what a name is before it’s used. Otherwise to read a file you have to zig-zag from the top to the bottom and back every time you encounter a new identifier.
What’s next, code like this?
fn add {
return result;
const result = a + b;
}(a: u32, b: u32) void
I’ll do it if zig fmt forces it on me, but I’ll be annoyed.
It’s fairly unusual, and IMHO suboptimal, for an entire file to be organized such that every name is defined before it’s used. That would tend to place small private methods at the top, and the important interface at the bottom, just by the nature of both.
So the question is whether @import should be special-cased the way you prefer, as it currently is, or dropped at the bottom out of the way. I don’t think I would be confused about seeing debug, std, ArrayList, and so on, before confirming that yep, those come from the expected place.
That isn’t as obviously true for within-project imports, of course. But the truth is that code is full of fields, methods, identifiers, which I haven’t seen yet. In practice I’ve found that putting the imports at the bottom is not a problem, because if I’m reading casually than a guess will do, but if I’m reading in anger then I’ll be able to jump to definitions.
zig fmt doesn’t have opinions about how this works at the moment, I’d prefer that it stay that way, code organization isn’t formatting.
My preference for imports at the bottom is pretty weak, frankly, easily outweighed by wanting to present code in a way that users will find to be familiar. But it’s there, and if Zig convention goes in that direction, I’ll change my code accordingly.
I think imports last is weird and won’t use it in my own projects. Maybe I’ll change my mind in the future.
The list of imports is actually helpful for quickly figuring out how a file fits in with the rest of a larger project, and what the dependencies between all the files are. I don’t think this should be hidden at the bottom.
VS Code is capable of collapsing import section of JavaScript and C files. That makes import spam somewhat less of an issue. Maybe we should stick with top import as the convention and leave it to code-editors/viewers to improve the user experience?
You can see @mlugg and @andrewrk discuss bottom imports a bit in the compiler development Zulip here: #compiler > (no topic) @ 
(note: only participate if you are actually working on the compiler)
Andrew Kelley: alright I’m inspired to keep trying out bottom imports some more
The ‘files with fields’ phenomenon mentioned is a pretty strong case for bottom imports. I’ve noticed that the fields feel ‘small’ or hard to find in that sort of file, and I suspect the pile of imports underneath the top-level doc comment is responsible for that feeling.
The biggest downside remains that people aren’t used to it, so it seems wrong. That’s a real thing, any language has an implicit ‘weirdness budget’ and it should be spent carefully. If too many people are just going to ignore the bottom imports convention, then we have a situation where it’s unpredictable to open any given file, which it currently isn’t. A bit like how a choice of tabs or spaces is always better than a mix of both.
The end of the file is 98% as easily accessible as the start. Ctrl+END is nearly universal, and almost as nearly universal is a “go-back” command.
So is showing a split view of a file or opening the same file in multiple panes so you can see the imports and the code at the same time.
It’s a stylistic choice, so most arguments can be called silly if you want. It doesn’t do anything other than being demeaning.
Odd is not the same word as silly. I see no intentional antagonism going on here, let’s keep it that way, thanks.
Must’ve read it wrong, sorry!
In any case, I think that moving from the prevalent way programs are structured in almost all languages, i.e. import first, to one that is basically the complete opposite requires a fair bit of motivation if it’s introduced in a tool newcomers are likely to use. It’s potentially confusing and offputting so no matter what choice each individual author or the Zig project itself uses the default choice for zig init should be the conventional way with imports first for the time being IMO.
However, if it turns out that most Zig projects finds imports last to be a good idea to the extent that it becomes the norm in the Zig community it should probably be changed to imports last.
Fields-in-file is a feature that always smacks of weirdness for weirdness sake. The only benefit is that it allows us to reuse “functional” structs (I.e. ones that we actually create instances of) as namespaces. More weirdness basically.
I think the only reason I prefer at the top is habit, if an import section became too large I would simply collapse it in my editor. I rarely open a source file from the top, most often I jump there by following a link anyways. So I would quickly get used to bottom in zig if key contributors preferred that.
However what I would really prefer are not one but TWO breaking changes. Since I don’t like all these breaking changes that’s actually something of a admission!
Only allow imports at the top or bottom (or both) just not in the middle of the file. Especially not deep inside of a function as you can today.
Split up std so that it doesn’t contain a ton of functionality that can be used for harmful stuff. (DynLib, elf, fs, io, process, and maybe others )
The rationale for this suggestion is actually as a former open source project maintainer, I often had to rely on others to do proper code reviews, having at most time to give some things a cursory look. I found it immensely helpful that I could simply look at the imports to determine what kind of attacks a file could contain. If there were no dangerous imports I was down to looking for funky pointer stuff. Again the code might be bad, it might have bugs, but I could vouch for that it at least wasn’t straight up malicious.
Zig actually has an advantage of importing into a const keyword that you can then search for to see how it’s used. That was a luxury I didn’t have back then.
Welcome to Ziggit @Joen-UnLogick!
The problem you’re referring to here is substantially mitigated in Zig, because @import is a builtin. Those have a distinct syntax, so a literal search for the string "@import" will always find all of them, it can’t be renamed or anything like that.
It used to be possible to import with a comptime-known string, but that was changed to only use a string literal, so that’s another way in which they’re pretty easy to audit.
I think there’s been some talk of only allowing it in the outer scope of a file, but given that files are just struct definitions, I would prefer that not happen for consistency’s sake. I don’t think that I’d need to change even one line of my code if it did happen though.
I think the primary reason is that the status quo (imports at top) does not use all of the “waypoints” in a file. A file has a beginning and an end, both of which are easy to jump to. The status quo under utilyzes the end waypoint (it is not used for anything right now).
However, having come from python, it is still a bit weird for me to think about having my dependencies not declared first.
Well…actually we do use the end waypoint, it’s the default location to add more code!