I wrote an AR archive (.a files) parser in D

[IchorDev]

On Thursday, 8 August 2024 at 16:42:30 UTC, Renato Athaydes wrote:
> On Thursday, 8 August 2024 at 11:07:35 UTC, IchorDev wrote:
>> Input parameters behave as if they have the const scope 
>> storage classes. Input parameters may also be passed by 
>> reference by the compiler.
>
> That's EXACTLY what I want! And it's shorter and nicer looking 
> than const. Sorry, but I will keep using it :).

You might’ve neglected to read the note above:

> **Note: The following requires the -preview=in switch, 
> available in v2.094.0 or higher. When not in use, in is 
> equivalent to const.**

Again, using previews in libraries is generally not great for 
code compatibility, but you will have to add the preview switch 
to your project for `in` to behave the way you want. Right now, 
your code is still using `in` as an alias to `const`, which could 
potentially become an issue if the new `in` behaviour becomes the 
default and your code doesn’t treat those parameters as if 
they’re also `scope`.

> Sorry, but have I made you angry somehow?
> Can we just talk in a civilized way please?

You were just wrong. It’s not uncivilised to point out how 
absurdly wrong you were. If you do not like being told that 
you’re wrong then don’t be wrong.

> I thought that functions from a module called `std.string` 
> would take, you know, strings.

`string` AKA `immutable(char)[]` and `char[]` are both ‘strings’, 
it’s just that we don’t usually pass around mutable strings.
Also `startsWith` is a `public import` from 
`std.range.searching`. How did you manage to call these functions 
without reading their documentation?

> `read` doesn't keep a reference to the byte array

That depends on the implementation of the function, which could 
change to keep a mutable reference without any warning since it 
isn’t `pure` or anything. Is it right to assume that a given 
impure function does not and will never in a future revision keep 
a mutable reference to its return value? I think not opening that 
can of worms is just simpler to manage, and `const` will work the 
same way in your case anyway. You’re not sharing data between 
threads or anything.

In your new code you’re casting to `const char[]` a lot when it 
would probably be preferable to cast to `const(char)[]` to avoid 
the headaches of having the array itself be `const`, thereby 
preventing you from reassigning to it. There’s rarely a reason to 
make an array `const` because it’s just a pointer and a 
length—it’d be like using `char const * const` in C.