I'm experimenting with several designs and I think I might have hit a bug, but I wanted to confirm it. Is this a bug?

    class A
    {
        void opDispatch(string name, T...)(T msg) {}
    }

    class B : A
    {
        C obj;
        alias obj this;

        @disable void opDispatch(string name, T...)(T msg);
    }

    class C
    {
        void foo() {}
    }

    void main()
    {
        auto b = new B;
        b.foo();
    }

 Output:

    Error: no property 'foo' for type 'B'

Disabling the opDispatch that B inherits from A also seems to disable B's alias this to C. The @disable works well in isolation -- as does the alias this, of course.

My current workaround:

    class B : A
    {
        C obj;

        void opDispatch(string name, T...)(T msg)
        {
            mixin("obj." ~ name ~ "();");
        }
    }

(which now makes me wonder what actually are the differences between those two...)

BTW, I was asking in the IRC channel (I should have discovered that lovely place earlier!) about the following:

1:    T[string] foo;
2:    foo[""] = new T;
3:    foo[null] = new T;

Lines 2 and 3 seem to do the same, apparently. People seemed to agree that 3 should not be relied upon (should it?), but if I recall/understand it was not totally clear to people why 2 and 3 *do* do the same thing, so feel free to clarify.

On Sunday, 10 November 2013 at 00:47:33 UTC, Luís Marques wrote:
> 1:    T[string] foo;
> 2:    foo[""] = new T;
> 3:    foo[null] = new T;
>
> Lines 2 and 3 seem to do the same, apparently. People seemed to agree that 3 should not be relied upon (should it?), but if I recall/understand it was not totally clear to people why 2 and 3 *do* do the same thing, so feel free to clarify.

2 and 3 do the same thing because an empty slice is the same as null. I personally think this is a bad thing.

On Sunday, November 10, 2013 05:58:53 Meta wrote:
> On Sunday, 10 November 2013 at 00:47:33 UTC, Luís Marques wrote:
> > 1:    T[string] foo;
> > 2:    foo[""] = new T;
> > 3:    foo[null] = new T;
> > 
> > Lines 2 and 3 seem to do the same, apparently. People seemed to agree that 3 should not be relied upon (should it?), but if I recall/understand it was not totally clear to people why 2 and 3 *do* do the same thing, so feel free to clarify.
> 
> 2 and 3 do the same thing because an empty slice is the same as null. I personally think this is a bad thing.

Actually, "" isn't null. They're equal, but they aren't the same. [] and null are the same, but "" isn't the same, because it's a string literal, and string literals have a byte with '\0' one past their end so that they can be passed directly to C functions. Now, for the purposes of AAs, "" and null would be equivalent, because

assert("" == null);

but

assert("" !is null);

- Jonathan M Davis

On Sunday, 10 November 2013 at 05:51:11 UTC, Jonathan M Davis wrote:
> Actually, "" isn't null. They're equal, but they aren't the same. [] and null
> are the same, but "" isn't the same, because it's a string literal, and string
> literals have a byte with '\0' one past their end so that they can be passed
> directly to C functions.

I didn't know that. How long has this been the case?

On Sunday, November 10, 2013 08:43:40 Meta wrote:
> On Sunday, 10 November 2013 at 05:51:11 UTC, Jonathan M Davis
> 
> wrote:
> > Actually, "" isn't null. They're equal, but they aren't the
> > same. [] and null
> > are the same, but "" isn't the same, because it's a string
> > literal, and string
> > literals have a byte with '\0' one past their end so that they
> > can be passed
> > directly to C functions.
> 
> I didn't know that. How long has this been the case?

Pretty much as long as D has existed AFAIK. If there was ever a time that it wasn't the case, it was before D hit 1.0.

- Jonathan M Davis