julia> struct A end
julia> as = [ A() for _ in 1:10 ]
10-element Vector{A}:
A()
A()
A()
A()
A()
A()
A()
A()
A()
A()
julia> sizeof(as)
0 # in bytes
julia> sizeof([ Int8(0) for _ in 1:10 ])
10 # in bytes
How would you reinterpret the 10 bytes taken up by those Int8 to the 0 bytes taken up by the As? It’s not per-se about the length of each array, but rather what has to happen to the underlying memory, as that’s what reinterpret is doing - reinterpreting how you interpret a piece of memory.
I’m deliberately showing arrays with elements in them here, as that’s something that has to be preserved when reinterpreting. The result of reinterpret is linked to the original array after all.
I believe the confusion here might comes from the fact that reinterpret works on the element sense:
julia> reinterpret(B, 1:10) # 1:10 is a lazy iterator
40-element reinterpret(B, ::UnitRange{Int64}):
...
For reinterpret(A, UInt8[]), since there’s no element in the array block, it’s understandable that it fails. --we might need some extra check to throw meaningful error messages, though. Making it a zero-sized ReinterpretedArray is also a valid result to me.
Yep, but in your example you do actually have numbers in your Int8[] arrays. Whereas, in my original example, the array itself is empty, so it can be readily reinterpreted, can’t it?
Which breaks down when the thing you reinterpreted to has sizeof(A) == 0.
Consider also the docstring:
help?> reinterpret
search: reinterpret
reinterpret(type, A)
Change the type-interpretation of a block of memory. For arrays,
this constructs a view of the array with the same binary data as
the given array, but with the specified element type.
Would you take a block of memory with length 0 as a block of memory (specifically in the context of reinterpret)?
I think I would, since the object I am trying to “view” also has size 0, I think.
Anyway, if everyone agrees this is how it is supposed to behave, which is understandable, maybe some checks to throw a more meaningful error as @JohnnyChen94 suggested might be of use to people who encounters this. Should I raise an issue in GitHub?
The object itself at time of reinterpreting does, yes, but that’s not the same as keeping that size over the lifetime of the object. reinterpreting empty arrays around seems rather odd to me, since you won’t be able to use them properly with elements inside of them. It’s similar to how padding has to agree for different structs to be allowed to be reinterpreted.
May I ask, how did you come across this?
Yes, that’s a good idea. Probably a check that the type to be reinterpreted to has sizeof != 0 (or only allow that if both source & target type have sizeof == 0)?
I am writing a Julia implementation of a protocol. Some of the messages of the protocol have size 0, since they have no contents further than a header (which is common to other types). However, it is still useful to know what type of message it was, since it can be used for dispatching.
I tried with a Tuple, but reinterpret works different for it.
Since I am reading from a stream, literally I am reading 0 bytes, so I had hoped that I could reinterpret it as I do for the other types (which all have a layout that is compatible with reinterpretation).
How would an Enum solve my problem here? By the way, I have literally 100 types of different messages
Ah, I see! Yes, an enum won’t help then. I don’t know what you’re doing with the read & reinterpreted block of memory, but I think reinterpret to empty singleton types is dangerous - you don’t have a link between the raw array and the resulting reinterpret anymore, as there’s nothing prevent the underlying array from changing. There’s also nothing to define how long the reinterpreted array should be, as that’s always tied to the size of the parent array.
which may work for you? The view is immutable, so won’t suddenly change where it looks or how long it is, so it should be safe. Is probably also safe for your other types, as long as the underlying data/array doesn’t suddenly vanish.
What error do you get?