property syntax strawman

[Andrei Alexandrescu]

Ary Borenszweig wrote:
> Andrei Alexandrescu escribió:
>> Marianne Gagnon wrote:
>>>> 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 liked the original idea... but this declaration syntax is a total 
>>> can of worms. Like others pointed out, would the compiler 
>>> automatically turn all functions with empty bodies into declarations? 
>>> Would empty setters be considered a declaration? What if I actually 
>>> *want*
>>>  to use an empty body as definition? Or what if I accidentally leave 
>>> a body empty when I didn't want to?
>>>
>>> Like someone else pointed out, existing keywords could be reused :
>>>
>>> bool empty
>>> {
>>>     in(bool value)
>>>     {
>>>         _my_empty = value;
>>>     }
>>>     out
>>>     {
>>>         return _my_empty;
>>>     }
>>> }
>>>
>>> I like this quite a bit.  I never wrote any compiler, granted, but I 
>>> don't think it'd be that hard to implement - and doesn't introduce 
>>> any new keyword.
>>
>> Please, please, could we look at something that does NOT go through 
>> two scopes to get to the code?
>>
>>> Or, alternatively, if you really wish to keep them separate, bool 
>>> empty= { ... } isn't intuitive, as Andrei pointed out, but is already 
>>> less error-prone than the empty-body declaration idea I believe
>>
>> I think void empty=(bool b) { ... } is a net win, which the forced 
>> bool empty=() diminishes. It would be great to keep the setter and 
>> find something as nice for a getter.
>>
>>
>> Andrei
> 
> int =empty() { } // getter

I suggested that but Walter mentioned there may be parsing problems when 
int is replaced with an elaborate type. (I am not seeing any.)

Andrei