opImplicitCast

[downs]

dsimcha wrote:
> Is opImplicitCast (and fixing opCast) anywhere in the pipeline?  It seems like
> every time I want to create an interesting library type, lack of
> opImplicitCast prevents me from making its API nice enough to be worth doing.
>  In some cases, alias this, which has been proposed,  isn't enough.
> 
> I've wanted an ArrayBuilder (with a capacity field) that can be implicitly
> converted to a regular array for the longest time.  The latest thing I want to
> do is write fixed point number structs for efficiently representing numbers in
> a narrowly defined range.  I often need to store, for example, huge amounts of
> real numbers between 0 and 1.  Space efficiency is important, very high
> precision isn't.  The obvious answer would be to use a ubyte or a ushort to
> represent it, with 0 representing 0 and ubyte.max or ushort.max representing
> 1.  I can't do this in a well-encapsulated, elegant way because so much
> functionality (both standard and homegrown math libs) assumes that numeric
> types are implicitly convertible to real, double, float, etc.
> 
> IMHO, now that we have ref returns, etc., lack of user-defined implicit
> casting rules is one of the few things preventing user-defined types in D from
> really being able to behave as if they were first-class types.  Does anyone
> else have some good real-world use cases for opImplicitCast, so we can start
> seriously considering how it should work?

Second and bump!