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.
