Revised RFC on range design for D2

[Christopher Wright]

Yigal Chripun wrote:
> auto test = new Test();
> auto y = &test.x; // consistent with the above
> auto g = &test.func; // this is inconsistent!
> in the above g is a delegate which is not a function pointer.
> just as int* is different from int[]. you wouldn't expect to get an
> int[] in the above, would you?

&obj.method returns a pointer to a method for this instance.
&obj.field returns a pointer to a field in this instance.

If &obj.method returns a function pointer instead, &obj.field should 
return an OffsetTypeInfo struct.

obj.field returns the value of the field.
obj.method returns the result of executing obj.method(). The value of a 
method is either its return value or the machine code that corresponds 
with that method; and it's rarely the case that you intend to deal with 
machine code as data.

Additionally, for obj.method to return machine code, D would have to 
support functions returning static arrays.

> a more consistent approach would be to have:
> - func and obj.method to be treated as delegates, of course for function
> pointers there should be an implicit cast to delegate.
> - &func and &obj.method would be strictly function pointers.
> - using parentheses is mandatory for function calls.

> IMHO, current low usage of delegates is not a reason to keep the current
> syntax but rather a result of the current syntax.
> 
> --Yigal

I wasn't aware that delegates were poorly used in D. If I had a use for 
event-driven design, I'd use delegates all the time. If I did functional 
programming, likewise.