I tend to agree with your aguments, because the half type could
be very useful to reduce memory usage of data stored as float for
lack of a smaller type.
The alternative us to use ushort everywhere, which is awkward,
because it
is neither unsigned, nor is it an integer, and it's not
typesafe (allows
direct assignment to ints and stuff)...
For better or worse, you can use a wrapper type around this
ushort:
https://github.com/p0nce/gfm/blob/master/math/half.d
It would be nice if: cast(half)someFloat would yield the proper
value, even
if it is performed in software in most architectures, it could
be mapped to
hardware for those that do it.
It could be done in a library, but then GCC couldn't map it
properly to the
hardware type, and
since D has no way to describe implicit casts (that I
know of?) it becomes awkward to use.
someFloat = someHalf <- doesn't work, because a cast operator
expects an
explicit cast, even though this is a lossless conversion and
should be
exactly the same as someDouble = someFloat.
When I first implemented half floats in D I came to the same
conclusion. Built-ins types have implicit conversion but one
can't define new ones.
Yet it's a trade-off probably choosen for good reasons. How to
make sure people won't abuse them? What to do with chained
implicit conversions?
