If you have an extension method for an array and try to call it from within a class or struct,   foo.bar will be looked up as if it were a call to this.bar(foo) instead of .bar(foo).  Now if bar were a static method of the class/struct, there might be a justification for that behavior, but for a normal instance member I don't think there's any good reason to interpret foo.bar as this.bar(foo), and it seriously interferes with the goal of adapting built-in types to existing interfaces.

-- test case below --
(think of it as a primitive attempt to support C++-like iterator syntax with D arrays)

int begin(T)(T[] x) {
    return 0;
}

struct Hi
{
    int begin() {
        assert(false, "I told you not to call me here!");
    }
    void smell() {
        float[] numbers = [1.0f,2,3,4,5];
        for (int i=numbers.begin(); i<numbers.length; i++) {
            
        }
    }

}
void main() {
    Hi you;
    you.smell;

//arrayover.d(27): function arrayover.Hi.begin () does not match parameter types (float[])
//arrayover.d(27): Error: expected 0 arguments, not 1