Property discussion wrap-up

[Maxim Fomin]

On Sunday, 27 January 2013 at 20:22:57 UTC, Zach the Mystic wrote:
> 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?

Unlike C, in D a function is not implicitly converted to pointer 
to function, and because you cannot create functions as stack 
variables, that statement should fetch 4.

>
> 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

Perhaps you mean function pointer or delegate.

> 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;

If you mean he suggests to implement properties through structs, 
than that is discussable, but if you mean that properties are 
like structs, than I found it is a bad idea, because structs and 
properties share almost nothing. Struct is an aggregate of 
objects of different types with methods and property is an 
abstraction over particular object which should not be accessed 
directly but through some procedure.

> 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
>   }
> }
>

So, solution is to use some unusual struct type as a wrapper on a 
member type. Why not default directly to real type like:

// in/out were suggested as D naming for getter and setter in the 
recent thread
struct S
{
     int foo
     {
         in { return ... } // or @set
         out { ...} // or @get
     }
}

Such sort of proposal introduces (like property-struct) 
significant change to syntax, so why not use fully the 
opportunity to make the syntax nicer?

> 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"); }