@property - take it behind the woodshed and shoot it?

[Artur Skawina]

On 01/27/13 13:02, Jacob Carlborg wrote:
> On 2013-01-26 22:48, Artur Skawina wrote:
> 
>> Hmm, the current state of them being defined by two separate functions really
>> isn't ideal. But introducing new keywords or magic identifiers just for this
>> does not seem right.
>>
>>     class A
>>     {
>>         private int i;
>>         int foo {
>>             out { return i; }
>>             in(int v) { i = v; }
>>         }
>>     }
>>
>> or
>>
>>     class A
>>     {
>>         private int i;
>>         @property foo {
>>             int out { return i; }
>>             in(int v) { i = v; }
>>         }
>>     }
> 
> That might conflict with contracts, which also uses "in" and "out".

It overloads the keywords, but afaict should be unambiguous and is not
worse than the other meanings of 'in' (operator, modifier). But I haven't
really used contracts w/ D (the basic features need to work right first,
before worrying about extras like that); somebody who actually uses them
would be in a better position to determine if overloading 'in' and 'out'
further would be too confusing.

I mentioned this as a possibility, but am not actually convinced that it's
a good idea yet. Things like mixin in getters and setters via separate
templates would be impaired - this may be unusual, but doesn't meet the
"insane" criteria, so shouldn't be disallowed. Which means several @property
blocks would have to be allowed and effectively merged together. 

artur