On Friday, 1 February 2013 at 17:23:45 UTC, Rob T wrote:
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.
Hey, thanks for coming back.
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).
I don't like this because structs don't already work that way.
All structs can work in exactly the same way. I'm pretty sure
there's no need to treat these specially... except under the
hood, where compiler optimizes away the unnecessary pointers in
the case of data-free structs.
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.
The problem with overriding "this" is if you later add data to
the struct, it will break any code that already uses "this".
"outer" doesn't have this problem at all, and is arguably
clearer. Therefore, I think "this" should simply be a
compile-time error with a data-free struct.
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 don't know, Rob T... Walter's recent article on half-floats
shows that you can get a struct instance to look pretty darn
close to a variable. Is there anything a variable can do that
half-floats can't do? Because if not, we're in the money, dude.
This does exactly the same thing, just with data stored outside
the struct itself.
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
Yes, but on the other hand, if you provide all the functionality
previously requested, plus a whole lot more, a compelling use
case becomes a lot less important. Undiscovered country.
