Community

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!