Possible @property compromise

[Zach the Mystic]

On Friday, 1 February 2013 at 06:52:32 UTC, Zach the Mystic wrote:
>> 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.

What I mean is, that the annoying aspect of making struct-nested 
structs act like their function-nested struct counterparts is 
that the part which is most difficult to implement will actually 
be the part people use the least. The main need is for data-less 
struct-nested structs to have access to their parent's scope, but 
implementing struct-nested structs which actually hold data will 
be more annoying, but it will be necessary for language 
consistency. But I though of a rather crude temporary fix. Simply 
disallow non-static struct-nested structs which actually hold 
data of their own. With this error built-in, all programmers can 
now tag all of their struct-nested structs with "static" until 
their program compiles once more. Now the language is clean and 
ready for the rather easy addition of data-less nested structs, 
and the slightly trickier data-ful struct-nested structs to be 
implemented when the developers get the chance.

All structs now will behave the same way, freeing up the 
Highlander syntax for use on *any* struct, data-less or data-ful.