Possible @property compromise

[Rob T]

On Friday, 1 February 2013 at 17:43:54 UTC, Zach the Mystic wrote:
[...]
>> 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.

It's one thing to implement a struct, and another thing to 
implement nested structs that can refer to the host instance. I 
know some people want nested structs that can work in that way, 
but implementation is problematic because when the host struct is 
moved, then the nested struct has to move along with it and this 
one reason why we don't have them.

I am proposing that we avoid the nesting problem by storing all 
enclosed data outside in the host instance, but this means that 
the concept is more like a namespace than a real struct, i.e., it 
is not movable and cannot be accessed in isolation from the host.

>> 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.

The idea here is that we have a property implementation that 
behaves like a namespace but also has some of the features that 
structs have. We should not call this thing a struct because it 
is not a true struct, it's something else entirely, not a 
namespace and not a struct, but it shares some features with both.

If you add data to the namespace-struct, the data is not stored 
inside the namespace, it only appears that way, it's instead 
stored with the hosting object instance, be it struct, class, or 
module, so data storage is like a namespace.

The "inner" simply refers to the "this" pointer of the host 
instance, but limited to the data that was declared inside the 
namespace, the outter pointer refers to the "this" of the host 
instance as well, but limited to the hosts data instance only. 
For modules I don't think there's a this pointer, but that's an 
implementation detail that can be resolved.

>>
>> 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.

The Half-Float implementation is not a nested structure, and 
trying to implement nested structs is where all of the major 
difficulties come from.

>> 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.

I think we can easily replace @property already with the 
namespace proposal, however it will not be the full variable 
emulation that some people had wanted.

I don't think full variable emulation can be done anyway and I've 
seen admissions that it cannot be done by some of the people who 
want to see full variable emulation. What we can get however is a 
much better implementation of the property concept through a new 
gadget that works like a namepsace with some of the nice features 
seen with structs. I doubt we'll ever see true nested structs 
that can reference data in a host structs instance and contain 
it's own data because it introduces a pointer sync problem when 
the structs are moved around.

At this stage in the discussion, I believe that Steven 
Schveighoffer is correct that we'll get more traction if we drop 
the nest struct idea and focus instead on implementing a D 
version of the C++ namespace, with the improvements that allows 
things like properties to be implemented.

If we can show that there are other uses for the idea, then it 
adds a lot more credibility to the idea because as it stands, we 
can get properties right now, but they suck (IMHO anyway). If the 
proposal is only a marginal improvement over what we have now, 
then it may not be seen as worth implementing.

--rt