Property discussion wrap-up

[Zach the Mystic]

On Wednesday, 30 January 2013 at 19:44:43 UTC, TommiT wrote:
> On Wednesday, 30 January 2013 at 18:05:08 UTC, Zach the Mystic 
> wrote:
>> [..]
>
> How about using this new namespace_thingy keyword:
>
> struct S
> {
>     private int value;
>
>     namespace_thingy prop
>     {
>         int get() { return value; }
>         prop opAssign(int v) { value = v; return prop; }
>
>         // int data; // error: can't have data here
>     }
> }
>
> The compiler would implicitly create something like:
>
> struct S
> {
>     private int value;
>
>     int prop_get() { return value; }
>     int prop_opAssign(int v) { value = v; return prop_get(); }
> }
>
> ...
>
> S s;
> int v1 = s.prop;        // lowered to s.prop_get()
> int v2 = (s.prop = v1); // lowered to s.prop_opAssign(v1)
> assert(v1 == v2);

I think you're thinking along the right lines, but this is no 
better than what's already been suggested. From everything I've 
read, reusing old keywords to do new things in new places is a 
time-honored D tradition, and adding new ones is very much 
frowned upon.

Also, because the "namespace_thingy"s have so much in common with 
structs, I think it would be misleading to call them something 
else. The lowering you're talking about already happens, in its 
own way, with the operator overloads. In fact, these overloads 
were designed *specifically* to allow struct and class instances 
to meld in seamlessly with built-in types.

Just look at Walter's recent article for half floats. The whole 
article demonstrates D's ability to do exactly what everybody is 
trying to get their properties to do. Now we just have to get rid 
of the performance overhead by treating structs with no data as 
namespaces instead of the more commonly held perception that they 
are only supposed to work on their own data! Hurrah!