half datatype?

[ponce]

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?