Since std.builtin.SourceLocation uses .line and .column for its position, reading a zig file at a SourceLocation requires counting new lines to find that position.
Having .offset as well could make it possible to read to a source location with readPositional or use a memory map and slice from the .offset without scanning the file.
I image it’s because source locations are very numerous (an additional field takes up memory) and the need to show source lines is rare and not in a hot path.
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ
i’m not sure if it’s this video
or this one
but i believe this exact question, or one extremely similar to it, is answered: it turns out to be faster for the compiler as a whole to not store but recompute.
Note that this is the return type of the @src builtin and not related to tokens or syntax nodes, which do use byte offsets instead of line/column. Pretty sure this is addressed in the video @alanza linked.
Here’s the context for why I wanted an .offset:
https://git.sr.ht/~glfmn/ouroboros/tree/main/item/src/test/snapshot.zig#L185-289
I had initially assumed that @src() would produce an offset so I could just memory map the file and slice to the source location to do the processing I need to do, and then @memmove and @memcpy to patch the file. The line column interface requires scanning all the pages, which maybe would have made just reading the entire file into memory with readFileAllAlloc or something worth it.