@property

[Jacob Carlborg]

On 2012-08-04 19:13, Adam D. Ruppe wrote:

> This would also fix things like
>
> func += 10;
>
> if func returned a ref int.
>
> ===
> @property ref int func() {
>          static int a;
>          return a;
> }
>
> void main() {
>          // all of these should work; func should look just like an int
> to the outside world
>          int a = func;
>          int* b = &func;
>          func += 10;
> }
> ===
> callexp.d(19): Error: cannot implicitly convert expression (& func) of
> type int function() @property ref to int*

I don't think that's correct behavior. I think the correct behavior 
would be to have a property rewrite, something like this:

foo += 10;

Is rewritten as:

auto __tmp = foo;
foo = __tmp + 10;

> Or something like that. Since @property ref int func() is supposed to be
> interchangable for a plain int func;, no special enforcement of
> @property syntax is required: it is illegal to call an int like a
> function, and func is an int as far as the outside world is concerned.
>
> This is how the property syntax is enforced: by the compiler's existing
> type checks. No additional code should be there to check syntax.
>
> So, I have two questions:
>
> 1) Do we all agree that @properties should be interchangeable for plain
> variables of the return value's type in all contexts? That is, if I can
> make this work with a pull request, is that going to be acceptable?

I think that you should always be able to replace a variable with a 
property. The other way around I'm not so sure. The problem is with 
methods in classes. Since a method will be virtual by default you can't 
just replace a property with a variable. That could potentially break 
subclasses that override the property.

-- 
/Jacob Carlborg