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?

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!