b.d:

struct B(T){

    private T x;// would normally prevent alias this from doing anything useful

    public alias x this; 

}

a.d:

void main(){

    auto a=B!int();

    a++;//should do a.x++; semantic change: even though x is private, public alias x this should behave as if x were public.

    //a.x++ should still be compile error of course.

    static assert(!__traits(compiles,a.x)); //fails but seems like a bug; I just reported it: 10170

}

I think this makes sense: 

* this allows protection (x is an implementation detail) so that 'this' behaves exactly as 'x'

* also, without this change of behavior, "alias x this" would not make much sense in terms of behavior outside the class (inside behavior should just access x directly)

Then, when multiple alias this statements will become allowed in D (will it?), we would have implemented something similar to go "embeddings" in GO (see http://golang.org/doc/effective_go.html)