On Fri, Apr 04, 2014 at 11:02:01 -0700, Walter Bright wrote:
> Most of the casts in Warp come from the workarounds I had to do to
> get around the auto-decode of std.array.front(). I have designed
> byChar, byWchar and byDchar ranges for Phobos to get around this
> issue, but that is stalled now because of the messed up design of
> ranges.

Sorry, I'm a D noob; what's 'auto-decode'?

> Here's one:
>   enum Index { A, B, C }
>   T[Index.max] array; // Error: Index.max is not an int
>   ...
>   array[B] = t;   // Error: B is not an int

Maybe instead of having array indices be int, having them specify some
interface (akin to Ix[1] used by Haskell's Array). Not that this is
likely fixable at this point.

> And another:
>   array[A + 1] = t; // Error: incompatible types Index and int
> And another:
>   enum Mask { A=1,B=4 }
>   Mask m = A | B;   // Error: incompatible operator | for enum

I like Qt's Q_FLAG and Q_FLAGS where you have a separate type for the
flags and combined flags. Maybe something like:

    enum MaskBits { mixin EnumBits!MaskBits; A=1, B=4 }
    alias Flags!MaskBits Mask;

where EnumBits would define the binary operations would be possible?

> And besides, even if such strongly typed enums were a good idea,
> making such a change would be an utter disaster for existing code. It
> is out of the question.


There's also Haskell's 'newtype' which might be useful to have
(strongalias? strictalias?). I guess this is no different than something

    class NewType(T) {
            T store;

            public this(T store) {
                this.store = store;

            package T unT() {
                return store;

and if you want unT to be public:

    public T unT(NewType!T nt) {
        return nt.unT();



Reply via email to