opImplicitCast

dsimcha dsimcha at yahoo.com
Fri Mar 20 09:17:43 PDT 2009


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?



More information about the Digitalmars-d mailing list