|Posted by downs|
in reply to dsimcha
Posted in reply to dsimcha
> 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!