Using memberspaces for a property-like syntax and more

[TommiT]

On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
>  First impression: I don't know why but I don't like it.
>
>  It feels like you're doing the following:
>
>  1) Declare a struct and immediately instantiate it with the 
> same name. (Or union, or similar)
>  2) Only one declaration of this struct can exist, doesn't 
> count as nested struct.
>  3) Disable all constructors/postblit/opAssign except as follows
>
>  [..]

Memberspaces shouldn't feel like variables at all. They should 
feel exactly like C++ namespaces that live inside a struct or a 
class. You can't take the address of a namespace or pass it as an 
argument. It's just an identifier that can be used to separate 
two same names, like std::sort and boost::sort. A nice IDE also 
colors memberspaces differently from a variables, etc.

On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
>  [..]
>  The only thing it has really done is allow you to force the 
> use of parenthesis during a call (but only the get, not the 
> set).

I thought it was an unfortunate side-effect that my proposal 
doesn't give us the nice getter syntax:
int n = var.prop;
...but I'm glad you like it (if I understood correctly).

On Saturday, 2 February 2013 at 13:03:49 UTC, Era Scarecrow wrote:
> [..]
> You're then defining all opBinary/opAssign methods that it 
> works with which seems like it will end up bloating the code 
> considerably but not giving back as much as it takes to write 
> it.

But luckily in D you can write a whole bunch of operators at once 
by writing a restricted template operator, like:

void opOpAssign(string op)(int rhs)
     if(op == "+" || op == "-" || op == "*"  || op == "/")
{
     mixin("_value" ~ op ~ "= rhs._value");
}

But you're right in that memberspaces require a more explicit 
declaration of a property than most other property 
implementations. But those property proposals where you only 
specify a getter and a setter, albeit faster to write, they all 
suffer from a possible performance issue when the type returned 
by getter is non-trivial to copy. I.e.
var.prop += 3;
...has to be done as:
var.prop = var.prop + 3

Also, those other property implementations don't enable you to 
call the methods of your property in an encapsulated manner. E.g. 
if you property has a non-const set_to_invalid method, you can't 
encapsulate further in the struct/class where the property is 
defined. I.e:
var.prop.set_to_invalid();
...calls directly PropType.set_to_invalid without the type of 
'var' having anything to say about it. That's not good for 
encapsulation.