Possible @property compromise

[Zach the Mystic]

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.