Jérôme M. Berger escribió:
Robert Fraser wrote:
Chad J wrote:
Nevermind properties. Any chance we can forbid the omittable
parentheses, at least in the lhs of an assignment expression?
In the more general case, any value type that gets modified but never
read or copied elsewhere is probably either dead code, a bug, or a
benchmark. The latter is easy to fix by adding the necessary read/copy
(return the value, pass it to a global or function, etc). It'd be great
if this kind of thing were a compile time error.
Code like this shouldn't compile:
struct S { int a = 0; }
S foo() { S s; return s; }
void main()
{
foo.a++;
}
Whatever solution to this is chosen *please* don't make "get", "set",
"value" or "prop" into keywords! "in", "out", "body" and "shared" used
to be common features of my coding style; I'm not sure it can take
another blow. As Andrei mentioned somewhere, keywords aren't cheap.
How about:
int x { setter, getter };
int setter();
void getter (int);
Where either one of the accessors may be null (or omitted):
int readonly { null, getter };
int writeonly { setter, null };
- It doesn't need a new keyword;
- It can't be confused with function declarations because those need
parentheses anyway;
- Ideally, the compiler would infer the type of the accessor from its
prototype (i.e if it doesn't take any arguments and returns T, then it's
the getter, if it takes a T and returns void then it's the setter,
otherwise it's an error).
Of course, this would *not* allocate any space in the class/struct.
Jerome
Please don't start a subthread about how to implement properties. I
think this is the third or fourth time this is discussed here. :)
The problem isn't the syntax; the problem is that none of the people who
make D see something useful in distinguishing properties from regular
function calls without parameters.
