property syntax strawman

[Ary Borenszweig]

Walter Bright escribió:
> Having optional parentheses does lead to unresolvable ambiguities. How 
> much of a problem that really is is debatable, but let's assume it 
> should be resolved. To resolve it, a property must be distinguishable 
> from a regular function.
> 
> One way is to simply add a "property" attribute keyword:
> 
>   property bool empty() { ... }
>   property void empty(bool b) { ... }
> 
> The problem is that:
> 
> 1. there are a lot of keywords already
> 2. keywords are global things
> 
> The alternative is to have a unique syntax for properties. Ideally, the 
> syntax should be intuitive and mimic its use. After much fiddling, and 
> based on n.g. suggestions, Andrei and I penciled in:
> 
>   bool empty { ... }
>   void empty=(bool b) { ... }
> 
> The only problem is when a declaration but not definition is desired:
> 
>   bool empty;
> 
> but oops! That defines a field. So we came up with essentially a hack:
> 
>   bool empty{}
> 
> i.e. the {} means the getter is declared, but defined elsewhere.
> 
> What do you think?

I like this. Of course there are better solutions, but this one is the 
one that involves less changes in the compiler.

It will also probably allow later to define things like:

int property+=(int value) { ... }
int property-=(int value) { ... }
int property*=(int value) { ... }

Of course it's very tedious to define all of these.

What I'd like the compiler to do, if you don't define property+=, is to 
transform this:

1. foo.property += 2;

into this:

2. foo.property = foo.property + 2;

only if a getter is also available. And if you do define property+=, 
then it is rewritten into:

foo.property+=(2);

This allows you to optimize some things. For example in C# there's no 
way to do this, if I'm not wrong.

Walter: what are the technical reasons for not transforming 1 into 2 
already?