Boy, std.bitmanip.bigEndianToNative is annoying to use

[H. S. Teoh via Digitalmars-d]

In the spirit of forum bickering, ;-) I stumbled upon this D wart today:
I'm reading some data from a file into a ubyte[] buffer, and I want to
use bigEndianToNative to convert ushort values in the file data into
native byte order (whatever the native order might be).

Sounds simple, right? Unfortunately, bigEndianToNative asks for ubyte[n]
as input. Meaning, this doesn't work:

	ubyte[] buf = ... /* allocate buffer here */;
	file.rawRead(buf);	// Read the data

	ushort myValue = bigEndianToNative!ushort(buf[4 .. 8]); // NG

The last line doesn't compile, 'cos you can't convert a slice of ubyte[]
into ubyte[4].

I can think of no easy way to declare a temporary ubyte[4] to make
bigEndianToNative happy, other than this silly verbosity:

	ubyte[4] tmp;
	tmp[] = buf[4 .. 8];
	ushort myValue = bigEndianToNative!ushort(tmp);

and I have to do this for every single numerical field in the data
buffer that I need to convert. :-(  Why should I copy data around that's
already sitting in a ubyte[] buffer intended precisely for the purpose
of doing such conversions in the first place??

The docs for bigEndianToNative claims that this is to help "prevent
accidentally using a swapped value as a regular one". But I say, "Why,
oh why???" :-(

This is a very anti-user kind of API. How did we think such a
straitjacketed API was a good idea in the first place?!


T

-- 
Curiosity kills the cat. Moral: don't be the cat.