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

IchorDev zxinsworld at gmail.com
Thu Aug 8 11:07:35 UTC 2024


On Thursday, 8 August 2024 at 10:44:49 UTC, Renato Athaydes wrote:
> Why shouldn't I cast the `read` result directly to immutable 
> when it's literally impossible to get a reference to those 
> bytes that is not immutable? It seems like the best way to 
> achieve what I need.

You’re still violating the guarantees of immutability—data can’t 
go from mutable to immutable, that’s what `const` is for. Using 
`const` would be totally fine, or you can use `.idup` to create 
an immutable copy of the array.

> Also, I thought `in` is the new way of using `const` parameters

No, it’s an old redundant way of using `const` for parameters. It 
also doesn’t let you specify what part of the type is constant, 
like `const(ubyte)[]` vs `const(ubyte[])`. It’s completely 
useless.

> and they're equivalent according to the docs.

In the future `in` might be replaced with a functional equivalent 
of `scope ref const` that binds rvalues, which is also mentioned 
in the spec. You can try this newer functionality with 
`-preview=in`, but using previews is not ideal for libraries. 
Also the new behaviour of `in` is basically a waste of time for 
arrays. It’s moreso for medium-sized structs that would actually 
be expensive to copy.


More information about the Digitalmars-d mailing list