You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic instead of using @mempcy for everything
Take the address and deref afterwards, and it's exactly the same. Or to say another way: if you want bits to be reinterpreted raw as if they're in memory, then... put them in memory, then reinterpret them.
> You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic
Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
> Take the address and deref afterwards, and it's exactly the same.
It is significantly worse to take address and deref afterwards.
You have to do something like:
@as(const u32, @ptrCast(&x)).
instead of just
@bitCast(x)
> Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
This makes sense except breaking existing code that properly handled endianness by doing a conditional @byteSwap. And what you end up with is a more complicated intrinsic compared to something that reinterprets values with same layout size
@ptrCast,
> Converts a pointer of one type to a pointer of another type. [1]
[1] https://ziglang.org/documentation/master/#toc-ptrCast
So it is not the same.
You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic instead of using @mempcy for everything
Take the address and deref afterwards, and it's exactly the same. Or to say another way: if you want bits to be reinterpreted raw as if they're in memory, then... put them in memory, then reinterpret them.
> You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic
Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
> Take the address and deref afterwards, and it's exactly the same.
It is significantly worse to take address and deref afterwards.
You have to do something like:
@as(const u32, @ptrCast(&x)).
instead of just
@bitCast(x)
> Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast.
This makes sense except breaking existing code that properly handled endianness by doing a conditional @byteSwap. And what you end up with is a more complicated intrinsic compared to something that reinterprets values with same layout size
2 replies →