Property discussion wrap-up

[Zach the Mystic]

Several suggestions here:

With regard to optional parentheses, it had been suggested that 
any ambiguity be regarded as an error. This is the example I used:

int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?

I suggested the ambiguity be resolved thus:

auto x = foo(); // parens to get the return value
auto y = cast(function) foo; // cast(function) gives the function

With regard to @property, Rob T suggested that properties are 
similar to structs, and Adam D. Ruppe suggested a struct might be 
definable as a single instance:

struct { ... } foo;

I suggested that the syntax be changed to put the name in front, 
with the simple switch of the normal "struct foo {}" to:

foo struct {} // No need for trailing semicolon now

All property methods can now be defined as you would for a normal 
struct, and the new syntax makes this, if I might say so, 
absurdly easy, assuming it's an unambiguous syntax as I think it 
is.

An enhancement to enforce the lack of parentheses would be define 
opGet, which disables opCall and disallows using parens when 
called:

struct gogo
{
   int _foo;

   // Note the switched tokens: means foo is the unique instance 
of the struct
   foo struct
   {
     int opGet() { return _foo; } // Enforces no parentheses
     int opCall() {} // Error: a struct may not have both opCall 
and opGet
   }
}

opGet's companion, opSet, could be syntax sugar for opAssign and 
opOpAssign, but I'm not sure how it would really work, or if it's 
even necessary. This:

ref int opSet( int rhs ) { _foo = rhs; return this; }

Could be lowered to something like this:

ref int opAssign( int rhs ) { _foo = rhs; return this; }
ref int opOpAssign( string op ) ( int newFoo ) { _foo = 
mixin("_foo" ~op~ " rhs"); }