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