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!
