property syntax strawman

[Andrei Alexandrescu]

Michel Fortin wrote:
> On 2009-08-02 03:43:43 -0400, Walter Bright <newshound1 at digitalmars.com> 
> said:
> 
>> 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) { ... }
> 
> Looking at it more carefully, this looks like an invitation to omit 
> parenthesis for functions with no argument. I mean, look at this and 
> tell me what it is?
> 
>     T transform { ... }
> 
> Is this a transform property (returning and affine transform) or an 
> action function returning transform? I'd guess it's a property since it 
> has no parenthesis, but nothing makes this very clear.
> 
> And could you do this? Would Andrei be tempted by this?
> 
>     void popFront { ... }

Good point! I continue to be unhappy about the designer having to think 
about inconsequentials like this.

> Note that I'm brigning this as an observation. Style guidelines can be 
> written mandating parenthesis for actions functions, which means my 
> problem of writing a coherent naming guideline is solved. But who read 
> the style guidelines?

Yes, yes, excellent point.

> While I like this syntax, the "getProperty()"/"setProperty()" syntax 
> (and also the "property" keyword syntax) has one advantage over this 
> one: it forces the interface to explicitly say "this is a getter/setter" 
> or "this is a property", which I expect would reduce abuses. It's the 
> same difference between as "opAdd" vs. "op+".

Walter made a compiler writer's point - now many symbols would have to 
be looked up twice instead of once. That is quite out of sync with 
everything else in the language.


Andrei