I've had to step away from this for a while, but I want to say
that I don't see a problem with the data-less "struct" property
idea at all, although calling it a struct is perhaps causing some
confusion because real structs tend to host internal data of
their own rather than reference it from the outside.
The proposed new type of property does not have to host its own
internal data, and its member functions can be called just like
the hosts member functions.
The proposed struct property is really something like a namespace
for wrapping data and related functions. It is not a regular
struct at all, but it does share some of the features of a
struct. It like an improved C++ namespace with smarts.
Syntactically, we can allow the property to contain its own data
internally, but the data will really belong to the hosted
structure (class, struct, or module level). Nothing really new
needs to be implemented because there's no special need for
storing a "this" pointer, and functions get called in the same
way as before. The "this" is the host pointer. We can still refer
to an inner and an outter this pointer, but that's really an
alias for either the hosts "this" (outter) or the property
namespace (inner), both use the same this pointer.
If we view the property more like a namespace, then certain
things become clear, for example the property by itself is not a
movable structure, it's permanently attached to the host class,
struct, or module. We can only take addresses of addressable
items if they are visible.
No, the struct-property will not behave exactly like a variable,
and I think that idea is a dead end anyway because it's far too
complicated to implement and has questionable value. I agree with
Walter, it's needs to be put down so we can move on and come up
with a better idea that can work and is really useful.
I may intuitively feel this is a great idea, but we will need a
few compelling use cases that solve real world problems to make
a case for it.
--rt
