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!
