--- Comment #7 from Peter Alexander <> 2012-01-20 
15:16:21 PST ---
(In reply to comment #6)
> The issue is the same for structs and any programmer who performs the cast is
> aware of it. (otherwise they wouldn't use a cast ;))

I'm am sure there are many programmers that are *not* aware of endianness, even
if they know that everything is made up of bytes and may use that cast.

I was unaware of the consistency though. Personally I consider the ability to
cast a struct to a ubyte[n] an error in the language design also. Consider:

ubyte[8] a = cast(ubyte[8]) iota(0, 8);

You get [0, 0, 0, 0, 8, 0, 0, 0]

I think this is something that an inexperienced D programmer could write
expecting to get [0, 1, 2, 3, 4, 5, 6, 7] back.

Furthermore, you cannot rely on cast(ubyte[N]) to return a reinterpreted struct
because the struct may define opCast for ubyte[N] (imagine a container struct
Array(T, size_t N) that has opCast for T[N] -- casting to ubyte[Array(T,
N).sizeof] will reinterpret in most cases, except when T=ubyte and N=the
sizeof, good luck finding that bug in your generic serialisation code).

Reinterpreting memory should require nasty pointer casts. It's not common (or
safe) enough to have convenient syntax, in my opinion.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to