On Thursday, 8 August 2024 at 11:07:35 UTC, IchorDev wrote:
> 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.
Wait a second... is that your opinion or official D's position? Because in
is documented as being used for function inputs:
> 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 :).
> That is plainly ridiculous. Read the documentation for these functions...
Sorry, but have I made you angry somehow?
Can we just talk in a civilized way please?
I thought that functions from a module called std.string
would take, you know, strings.
> Is this likely to affect your small case? Technically no, but it’s the first step down the dangerous path of lying to the compiler,
The program works and I didn't lie to the compiler. read
doesn't keep a reference to the byte array, and there's no way to access it since I cast it before assigning it. I get your point, but I don't see why insist on not casting to immutable even when it's patently safe to do so.