Possible @property compromise

[Zach the Mystic]

On Friday, 1 February 2013 at 04:33:05 UTC, Steven Schveighoffer 
wrote:
> On Thu, 31 Jan 2013 19:59:46 -0500, Zach the Mystic:
>> 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.

How does any function get hooked up with data? The compiler 
figures out what data is to be passed to which function. It's no 
different from how the compiler figures out how to pass data 
defined in one module to functions defined in a different module. 
Empty structs are just namespaces with powerful semantics. They 
have no pointers, unless they're nested in a struct with data, in 
which case they have the same pointer as any member function of 
that struct.

struct A
{
   int q = 23;
   void incrementQ() { ++q; }
}

How on earth could this function increment q when it's not even 
defined in the function?!?!? It must be a miracle. Oh, no wait, 
it needs a pointer to the struct in question. Duh.

There's no difference with data-less structs inside regular 
structs.

struct A
{
   int q;
   incrementQ struct
   {
     void opCall() { ++q; }
   }
}

Where's the need for some hocus-pocus mystery pointer here? The 
empty struct has no data to worry about. Functions inside the 
empty struct get the same damn pointer as the other functions in 
struct A. But of course, you can't do this:

struct B
{
   int _q;
   q struct
   {
     int opUnary(string s)() if (s == "++")
     {
       writeln("You know, I just wanted to have a conversation 
while I was busy incrementing q");
       ++_q;
       writeln("I did all sorts of stuff with the increment 
operator while I was at it");
       return _q;
     }
   }
}

...with normal function calls.

> Unless, of course, you pass the pointer to myStruct as the 
> 'this' reference.

Ain't no "this" in an empty struct. Use "outer.this" instead.

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

Because it's already implemented, except for a few details, 
because it opens up possibilities for properties other languages 
could only dream of, and because it obviates the need for tags 
like @property to provide far weaker functionality.

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

Yeah, see, the problem is, if empty structs, which require no 
"this" pointer to themselves, are allowed access to their parent 
scope, it suggests that all structs should do the same. Now we 
have one good syntax for these things : "foo struct { ... }", 
which could be fun to use in other places too (where you want a 
single instance of a struct). But if these empty structs are 
fundamentally different from regular structs, it will force a 
situation where the Highlander syntax must be used only on these 
"special" structs, to make sure the compiler knows the 
difference. It's a problem, to be sure.

> 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

You say it's complicated, but I ask you this: does any other 
proposal completely eliminate the so-called eye-sore "@property" 
while also providing functionality with unknown potential which 
goes far beyond what people are used to? And the owner pointer 
problem is only a problem if we want to make the language 
complete and consistent with regard to normal non-static structs 
holding an outer struct pointer. I think having a use case for 
this type of struct would seal the deal, but as it is, I'm not 
sure.