http://d.puremagic.com/issues/show_bug.cgi?id=7328
--- Comment #7 from Peter Alexander <peter.alexander...@gmail.com> 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); writeln(a); 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------