h3r3tic	imo it shouldnt work... if it worked, one would assume it to work for delegates as well. but delegates support the .ptr property so it couldnt work with them.

previous code compiles with DMD 1.021, don't know if any ealier version fixes the behavior, while the following ambiguous is related to this change (mentioned by h3)
void[] t(){return null;}
class v
{
	void[] k(){return null;};
}
void main()
{
		void[] delegate() dg;
		auto inst= new v;
		dg= &inst.k;
		assert(dg().ptr is null);
		assert(dg.ptr is null);
        void* m;
        m=t().ptr;    //compiles
        m=t.ptr;      // fails, i'm worry about if let it through , maybe we will have buggy code. but due to D's documentation this should be compiled
}

Both examples compile in D 2.031.

Should this be marked as resolved?

(In reply to comment #3)
> Both examples compile in D 2.031.
> 
> Should this be marked as resolved?

The second example *compiles* but the second assertion fails.

The problem with this code is that compiler doesn't know if you ask for:
1) a pointer of the base of the void[] array returned from t (used as property)
2) or a pointer of the t function/delegatel

This situations will be partially cleaned up when functions/delegates calls will require ().

The specs need to specify what's the behaviour of using the .ptr of a @property delegate that returns an array (or that returns anything that has a ptr field):

void main() {
    @property int[] delegate() bar1 = { return [1, 2]; };
    struct Foo { int* ptr; }
    @property Foo delegate() bar2 = { return Foo(); };
    auto x1 = bar1.ptr;
    auto x2 = bar2.ptr;
}

Commit pushed to https://github.com/D-Programming-Language/d-programming-language.org

https://github.com/D-Programming-Language/d-programming-language.org/commit/1d2c1213537ec642c5b1ec2526d0b26e1196da80
fix Issue 678 - Compiler accepts, for a function T[] t(), t().ptr but not t.ptr

Spec clarified.