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.
