Possible @property compromise

[Steven Schveighoffer]

On Thu, 31 Jan 2013 19:59:46 -0500, Zach the Mystic  
<reachBUTMINUSTHISzach at googlymail.com> wrote:

> I think my suggestion goes far beyond what you suspect. It goes way  
> beyond mere getting and setting of variables. Here is basically how you  
> implement a basic int as a property, assuming my new syntax and language  
> adjustments. You need: 1) a struct to have the property in, which is  
> just a normal struct. 2) An actual integer which will be indirectly  
> accessed by using the properties. Let's call it "_n" and the property  
> "n". 3) a struct to hold all of the property functions which access _n.  
> THIS STRUCT CONTAINS NO DATA OF ITS OWN. 4) A bunch of methods  
> implementing all the operators you want. For int, that's quite a lot, so  
> I'll shorten it to a getter, a setter, and an adder. I'll even leave out  
> opGet and use an alias to what might as well be opGet. I'll give the  
> adder a little personality because what's the point of properties if  
> they don't do something different from a basic type?
>
> struct myStruct
> {
>    int _n;
>    n struct
>    {
>      int __mightAsWellBeOpGet() { return _n; }
>      alias __mightAsWellBeOpGet this;
>
>      int opAssign(int newN) { _n = newN; return _n; }
>      int opBinary(string op) (int rhs)
>      {
>        static if (op == "+")
>        {
>          writeln("You sure are adding a funky int, my friend...");
>          return _n + rhs;
>        }
>        else static assert(0, "Operator "~op~" not implemented");
>      }
>    }
> }
>
> This is not some kind of special property implementation. n is a struct.  
> It has no data and therefore is a very peculiar kind of struct. A struct  
> with no data needs only one instance, ever. Copying it is pointless.  
> Taking its address is pointless. Creating a new instance is pointless.  
> Passing it by ref is pointless. All operations which require more than  
> one instance are pointless, which is why it doesn't need a separately  
> defined type. The type and the instance can therefore use the same name,  
> n in this case.

No, the struct must have data.  If it doesn't, how does it get back to the  
owner type?  In other words, your n struct must have a pointer to the  
myStruct instance it intends to modify _n on.

Unless, of course, you pass the pointer to myStruct as the 'this'  
reference.  But then, this isn't a normal struct, and I'm really failing  
to see why we have to make this a struct at all.

> Note that n uses the new rule which allows it access to its parent's  
> scope, the same way it would in a nested function. The only pointer it  
> needs is the same pointer used for myStruct, since myStruct actually  
> stores some data.

FYI, nested structs in functions (the ones you want to use as a model)  
have an extra hidden reference pointer back to the stack frame data.  That  
is how they can access the local variables of the function.

This proposal looks way too complicated.  I don't see how it's a win over  
the current state of affairs, or even the @property implementation we  
expected to get but didn't.  You need to solve the "owner pointer" problem  
before it's even viable.

-Steve